With the multi-issuing (per dot) of CMD10 it now consistently produces an error message on unusable rxlag values.
I've worked out that not all SD cards react the same to pin registration. Then the timing compensation causes lsb ordering mismatch. I'm not sure of best way to resolve. I've already improved the outcome by widening the min-max search of the calibration routine so that it still finds all good cases. But when using clock divider of 2 it can still end up picking the wrong value for rxlag.
I could reject the choice on basis that that value failed and select plus/minus one instead. Or I could try separating the pin registration step so that the search order isn't based on preconceived behaviour of the SD cards.
EDIT: Okay, it's really at the edge of that particular card's ability I think. ie: Not a Prop2 timing limitation. Older cards are sometimes slower unsurprisingly.
Amusingly, another SD card, the camera card, of the same brand but 6 years older is actually a faster card.
Well, I've simply made it subtract one for correcting rxlag when it hits the mis-ordered registration issue. The default choice was rounded up on halfway. So it now kind of rounds down for this exception.
@evanh said:
EDIT: Okay, it's really at the edge of that particular card's ability I think. ie: Not a Prop2 timing limitation. Older cards are sometimes slower unsurprisingly.
I would imagine there is going to be quite a bit of variation in delay required amongst different cards at the same P2 clock freq and divider, which affects the rxlag value needed. As so many different types of cards have been released from different manufacturers there is unlikely to be some one size fits all value. Not going to be something like the PSRAM output timing from the same manufacturer for example.
Comments
With the multi-issuing (per dot) of CMD10 it now consistently produces an error message on unusable rxlag values.
I've worked out that not all SD cards react the same to pin registration. Then the timing compensation causes lsb ordering mismatch. I'm not sure of best way to resolve. I've already improved the outcome by widening the min-max search of the calibration routine so that it still finds all good cases. But when using clock divider of 2 it can still end up picking the wrong value for rxlag.
I could reject the choice on basis that that value failed and select plus/minus one instead. Or I could try separating the pin registration step so that the search order isn't based on preconceived behaviour of the SD cards.
EDIT: Okay, it's really at the edge of that particular card's ability I think. ie: Not a Prop2 timing limitation. Older cards are sometimes slower unsurprisingly.
Amusingly, another SD card, the camera card, of the same brand but 6 years older is actually a faster card.
Well, I've simply made it subtract one for correcting rxlag when it hits the mis-ordered registration issue. The default choice was rounded up on halfway. So it now kind of rounds down for this exception.
I would imagine there is going to be quite a bit of variation in delay required amongst different cards at the same P2 clock freq and divider, which affects the rxlag value needed. As so many different types of cards have been released from different manufacturers there is unlikely to be some one size fits all value. Not going to be something like the PSRAM output timing from the same manufacturer for example.