Yeah, with this program flashed, uSD no longer works at all:
trying \\.\COM32...
P2 version G found on serial port \\.\COM32
Setting load mode to CHIP
Setting clock_mode to 12427f8
Loading fast loader...
Loading E:/Parallax/Prop2/Stamp/uSD_Issue/eeprom_check.binary - 53108 bytes
address=0x00000000 size=cf74
device response to header: `s'
chksum: 58 OK
( Entering terminal mode. Press Ctrl-] or Ctrl-Z to exit. )
clkfreq = 200000000 clkmode = 0x10009fb
Compiled with FlexC v7.4.2
... /sd1 open failed! errno = 0: OK
Clean-up ... errno = 0: OK
Ok, so don't know exactly what this unit was flashed with before starting these tests... Could have been nothing, or could have been something with FSRW. Thinking nothing though...
Flashing with a blank program doesn't fix it...
@evanh This particular SWaP module may be different. It's one we paid to have made.
FSRW mount fails. But, just trying it makes the eeprom_check.c code work...
Will have to try this exercise again on one of the new modules...
4k7 seems too low. That slurps almost a whole mA when being driven down.
Maybe the problem can be fixed in software by driving all the ostensibly pulled up pins high for a bit before trying to mount?
Unsure if this is actually a timing thing. It could be crosstalk. It's always a risk leaving digital inputs dangling. The noisier the environment, and more directly exposed, the worse they behave.
I guess I need to use some 100k resistors myself and see where things go wrong ...
Pin P58 seems to have a pull-down on it. It floats to 0.86 Volt when I use a 47k pull-up resistor. The card busy check times out waiting for that pin to rise.
EDIT: Oh, duh! I see R24 is indeed a pull-down where it should be a pull-up. I'd assumed it was a pull-up earlier.
EDIT2: And even though my older schematic doesn't show R24 existing it must actually be there in my Swap module. I measure a tidy 10k to GND on P58. So it was just fortuitous I happen to use a 4k7 pull-up to get things working earlier. I'd run out of 10 k's on hand.
Yep, that's it. Found R24 on the bottom side of the Swap module, under the SD slot. Removed it and now a 47k pull-up resistor is working fine. And done without the fancy pin drive mentioned below. I'd removed this code in my testing SD driver trying to work out the problem.
PS: The built-in SD driver also configures that pin to drive high with a 15kR drive, an effective extra pull-up. But that wasn't quite enough to beat the 10k pull-down.
So the problem wasn't because of cross-talk or any type of noise, nor was it a timing issue.
Can't say why FSRW gets results. Maybe the driver is not doing a card busy check at that critical point during init. Then once the SD card is init'd the SPI mode probably maintains DO as driven. That would then beat the pull-down.
If it is the older sdspi_bashed2.spin2 driver then it doesn't do any card busy checks at all.
On some of the ones that came assembled, the uSD won't work at all. That may be because a 1.8 V hyperram chip was installed on those. Even with it disabled via solder jumper, it doesn't work...
Interestingly though on the ones where uSD it does work, seems hyperram works as well...
@Rayman said:
Tried various options in sdmm.cc but nothing makes it work...
//_wrpin(PIN_DO, P_INVERT_OUTPUT | P_HIGH_15K | P_LOW_15K); // config for 15 k pull-up
//RJA
_wrpin(PIN_DO, P_INVERT_OUTPUT | P_HIGH_FAST | P_LOW_FAST); // config for XXX
Actually, there is trickery going on with that pin. That particular line of code is redundant with the ordering of boot pins. It only comes into effect when DO pin is more than 3 pins distance from CLK pin. It allows Roger Loh's 4-bit SD card pinout to be operated using this driver.
The SMPIN_DO is the one you want to be editing to make DO pin mode changes when DO is near CLK.
PS: It was all a hack originally but it worked well for the situation at the time and didn't have negative effects other than the extra code size, so I just left it in place. And I have often, subsequently, used it with Roger's adaptor when comparing different driver performances.
Comments
@evanh Your pullups are all different than Rev.D. Much lower resistance looks like.
Guessing that is the difference...
Certainly possible. I didn't like the listed 100k values in the schematic.
Give my program a try before you change anything.
@evanh Looks like your test worked:
Doesn't work when from "cold boot" what that program is flashed though.
Also, has gotten itself into a state where won't work when downloaded over serial:
Yeah, with this program flashed, uSD no longer works at all:
Running FSRW first fixes it, same as before.
Ok, so don't know exactly what this unit was flashed with before starting these tests... Could have been nothing, or could have been something with FSRW. Thinking nothing though...
Flashing with a blank program doesn't fix it...
@evanh This particular SWaP module may be different. It's one we paid to have made.
FSRW mount fails. But, just trying it makes the eeprom_check.c code work...
Will have to try this exercise again on one of the new modules...
Here's my soldering job of the pull-ups.
PS: The camera isn't great at showing the red and orange stripe colours on the resistors. I have confirmed the resistances with a multimeter.
Ok, checked with new module and it fails at powerup with this program in flash.
Works when FSRW is in flash though...
Yep, so the 100k resistors are just too high value. They need replaced. I'd go with 4k7 all round.
4k7 seems too low. That slurps almost a whole mA when being driven down.
Maybe the problem can be fixed in software by driving all the ostensibly pulled up pins high for a bit before trying to mount?
Unsure if this is actually a timing thing. It could be crosstalk. It's always a risk leaving digital inputs dangling. The noisier the environment, and more directly exposed, the worse they behave.
I guess I need to use some 100k resistors myself and see where things go wrong ...
It might be tough to label as hardware problem or software problem…
But, seeing as software can fix it…
Pin P58 seems to have a pull-down on it. It floats to 0.86 Volt when I use a 47k pull-up resistor. The card busy check times out waiting for that pin to rise.
EDIT: Oh, duh! I see R24 is indeed a pull-down where it should be a pull-up. I'd assumed it was a pull-up earlier.
EDIT2: And even though my older schematic doesn't show R24 existing it must actually be there in my Swap module. I measure a tidy 10k to GND on P58. So it was just fortuitous I happen to use a 4k7 pull-up to get things working earlier. I'd run out of 10 k's on hand.
Yep, that's it. Found R24 on the bottom side of the Swap module, under the SD slot. Removed it and now a 47k pull-up resistor is working fine. And done without the fancy pin drive mentioned below. I'd removed this code in my testing SD driver trying to work out the problem.
PS: The built-in SD driver also configures that pin to drive high with a 15kR drive, an effective extra pull-up. But that wasn't quite enough to beat the 10k pull-down.
So the problem wasn't because of cross-talk or any type of noise, nor was it a timing issue.
Can't say why FSRW gets results. Maybe the driver is not doing a card busy check at that critical point during init. Then once the SD card is init'd the SPI mode probably maintains DO as driven. That would then beat the pull-down.
If it is the older sdspi_bashed2.spin2 driver then it doesn't do any card busy checks at all.
Ok, Rev.D does have this 10k pulldown on P58 using R24:
https://www.rayslogic.com/Store/SWaP/SWaP_Schematic.pdf
Would changing the FatFs driver to use 3.3k drive fix this issue?
Ada, kick Rayman for me will you?
Get in there with your soldering iron and disappear that resistor! It's small but not a hard job.
It really should have a pull-up added. Flexspin's built-in driver doesn't need it but other solution likely will.
Have determined that flashing with a code that toggles P58 and P59 does mess up both FSRW and FatFs.
So, that's a bad idea...
Too bad, cause that was nice to flash the onboard LEDs to show it had power...
Have to see what one can get away with on at least one of these pins...
Tried various options in sdmm.cc but nothing makes it work...
//_wrpin(PIN_DO, P_INVERT_OUTPUT | P_HIGH_15K | P_LOW_15K); // config for 15 k pull-up //RJA _wrpin(PIN_DO, P_INVERT_OUTPUT | P_HIGH_FAST | P_LOW_FAST); // config for XXXOn some of the ones that came assembled, the uSD won't work at all. That may be because a 1.8 V hyperram chip was installed on those. Even with it disabled via solder jumper, it doesn't work...
Interestingly though on the ones where uSD it does work, seems hyperram works as well...
Actually, there is trickery going on with that pin. That particular line of code is redundant with the ordering of boot pins. It only comes into effect when DO pin is more than 3 pins distance from CLK pin. It allows Roger Loh's 4-bit SD card pinout to be operated using this driver.
The SMPIN_DO is the one you want to be editing to make DO pin mode changes when DO is near CLK.
PS: It was all a hack originally but it worked well for the situation at the time and didn't have negative effects other than the extra code size, so I just left it in place. And I have often, subsequently, used it with Roger's adaptor when comparing different driver performances.
Noticed something else interesting...
With nothing loaded in the flash, inserting a uSD kills the serial comms. Won't identify at all...
Yet another puzzle...