Hello,
I am asking about this issue partly because I think it may be of interest for PRJC too look into as well.
Might also not be, I suppose
We are in a situation where we have had to extend the Teensy 4.1 SD card slot using an extension cable connected via the on-board SDIO socket (SdioTeensy.c in effect).
We initially did this using a hand-built 1.27mm ribbon cable attached to an µSD shaped board on one end and a board with an SD-card socket on the other.
This worked well.
We later upgraded the cable to a production-friendly Rigid+FlexPCB which, due to it's thinner structure, has slightly higher capacitance.
This cable does not work at all.
What is interesting is that the cable does work perfectly with Teensy 3.2, Teensy 3.6, other custom microcontroller boards as well as every PC USB SD-card reader we've tested - the cable fails exclusively with Teensy4.1.
We have, of course, played around with drive strengths on the SD pins, print debugging over USB serial, and scope measurements of the signals.
It turns out that failures most often occur as early as the 400kHz initial rate, but sometimes we get all the way to running at 25MHz high-speed for some short duration before it fails. Some Teensy 4.1s consistently don't manage to get even a single transaction through.
The signals and the eye diagram are, as expected, absolutely pristine in 400kHz mode.
Ringing (measured with a 200MHz scope) does not indicate this to be an issue.
At 25MHz there is natural degradation of the eye diagram, but nothing that would typically warrant suspicion.
Drive-strength changes have the expected impact on signal transitions, but little to no effect on the problem across the full range of configurable strengths.
We have attempted to get suggestions from NXP support, which yielded no results.
It has later been shown that the initial ribbon cable, even though it appeared to work well, also has issues (again, with Teensy 4.1 only).
Sometimes, although quite rarely, communications do fail - which has warranted us to implement a re-initialize and retry functionality that works around most of these issues.
We've not error checked our file.printf calls (which I am not exactly certain how to do at this point) so this still came back to bite us recently.
Sometimes the system ends up in a state where every call to write data takes approximately 1 second before returning.
This, of course, appears to hang the system when a large number of writes are done in direct succession.
After dumping the stack using an interrupt we found that this time is spent in waitTimeout (via isBusyTransferComplete, waitTransferComplete, SdioCard::writeSector, etc.).
That's what I've got at this point - here's hoping for any sort of suggestion on reconfiguring the SD card peripheral to better cope with this situation, which seems obviously possible given that it works with "everything" else.
NXP supports suggestion of "don't use the cable" is not really an option
Thanks for your time!
I am asking about this issue partly because I think it may be of interest for PRJC too look into as well.
Might also not be, I suppose
We are in a situation where we have had to extend the Teensy 4.1 SD card slot using an extension cable connected via the on-board SDIO socket (SdioTeensy.c in effect).
We initially did this using a hand-built 1.27mm ribbon cable attached to an µSD shaped board on one end and a board with an SD-card socket on the other.
This worked well.
We later upgraded the cable to a production-friendly Rigid+FlexPCB which, due to it's thinner structure, has slightly higher capacitance.
This cable does not work at all.
What is interesting is that the cable does work perfectly with Teensy 3.2, Teensy 3.6, other custom microcontroller boards as well as every PC USB SD-card reader we've tested - the cable fails exclusively with Teensy4.1.
We have, of course, played around with drive strengths on the SD pins, print debugging over USB serial, and scope measurements of the signals.
It turns out that failures most often occur as early as the 400kHz initial rate, but sometimes we get all the way to running at 25MHz high-speed for some short duration before it fails. Some Teensy 4.1s consistently don't manage to get even a single transaction through.
The signals and the eye diagram are, as expected, absolutely pristine in 400kHz mode.
Ringing (measured with a 200MHz scope) does not indicate this to be an issue.
At 25MHz there is natural degradation of the eye diagram, but nothing that would typically warrant suspicion.
Drive-strength changes have the expected impact on signal transitions, but little to no effect on the problem across the full range of configurable strengths.
We have attempted to get suggestions from NXP support, which yielded no results.
It has later been shown that the initial ribbon cable, even though it appeared to work well, also has issues (again, with Teensy 4.1 only).
Sometimes, although quite rarely, communications do fail - which has warranted us to implement a re-initialize and retry functionality that works around most of these issues.
We've not error checked our file.printf calls (which I am not exactly certain how to do at this point) so this still came back to bite us recently.
Sometimes the system ends up in a state where every call to write data takes approximately 1 second before returning.
This, of course, appears to hang the system when a large number of writes are done in direct succession.
After dumping the stack using an interrupt we found that this time is spent in waitTimeout (via isBusyTransferComplete, waitTransferComplete, SdioCard::writeSector, etc.).
That's what I've got at this point - here's hoping for any sort of suggestion on reconfiguring the SD card peripheral to better cope with this situation, which seems obviously possible given that it works with "everything" else.
NXP supports suggestion of "don't use the cable" is not really an option
Thanks for your time!
