For reference this is the circuit I used for the SD on this board - it follows the same pin order as initially given in the SD card thread, although I didn't add the SD power LED to the 8th pin in this case as it is hidden inside the cartridge but I did include the general purpose LED on the 7th pin (also useful for debugging when standalone - eg. to find the xtal osc problem I had). Because I didn't have the power LED I just included a 1k8 to ground from the SD power supply to discharge the caps faster when the FET is turned off.
The V_USB and SENSE signals are not part of the SD stuff, they just happened to make use of a spare 22k resistor I had nearby for sensing 5V on the USB-C cable that can be optionally plugged-in.
Discharge resistor isn't needed. The power LED stops conducting very early in discharge curve. The driver software pulls all the DAT and CMD pins low to drain caps. It takes about 37 28 milliseconds via the five 22 kR resistor paths.
PS: The level is monitored on the CLK pin so if it takes longer then no issue.
Our external power feed resistor has now been cut and it runs the SD card test from inside the GPi case on it's internal Lipo powered 5V supply, with USB-C plugged directly into the cartridge. No more external supply shorting risk.
Now I just need to context switch back to messing with all the prior NeoYume settings etc - am a bit rusty for all that as it was several weeks ago now and I've been in HW mode since.
@evanh said:
Actually, if you turn on -D SD_DEBUG it'll report how quickly the power-down happened.
Just ran it again. But I see it did report some CMD10 errors before things ultimately worked, are they important?
( Entering terminal mode. Press Ctrl-] or Ctrl-Z to exit. )
clkfreq = 128000000 clkmode = 0x10001fb
SD card driver (4-bit SD mode) v1.12
sdsd_open: using pins: 53 52 48 55 54
Card detected ... power cycle of SD card
power-down threshold = 37 pin state = 1
power-down slope = 29633 us pin state = 0
SD clock-divider set to sysclock/320 (400 kHz)
Card idle OK
OCR register 80ff8000 - SDSC Card
Data Transfer Mode entered - Published RCA 1ff30000
CID register backed up
4-bit data interface engaged
Speed Class = C4 UHS Grade = U0
Video Class = V0 App Class = A0
Cache = 0 Queue = 0
TRIM = 0 FULE = 0
Card User Capacity = 1920 MB (1.88 GB)
High-Speed access mode engaged
SD clock-divider set to sysclock/4 (32.0 MHz)
. CMD10 error!
. CMD10 error!
. CMD10 error!
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
. CMD10 error!
. CMD10 error!
. CMD10 error!
. CMD10 error!
. CMD10 error!
. CMD10 error!
. CMD10 error!
. CMD10 error!
. CMD10 error!
. CMD10 error!
. CMD10 error!
. CMD10 error!
. CMD10 error!
rxlag=8 selected Lowest=4 Highest=11
CID decode: ManID=02 OEMID=TM Name=SD02G
Ver=3.2 Serial=a8ab6696 Date=2008-4
SD Card Init Successful
/sd1 handle = 105f0 ... mounted
@rogloh said:
Just ran it again. But I see it did report some CMD10 errors before things ultimately worked, are they important?
Thanks. Those errors are complete normal, it's the calibration routine making use of the regular command/response functions to find the good/bad boundaries of rxlag setting.
@Wuerfel_21 I have ported your emulators to my updated HW and ran into some issue after loading screen. Screen changes and freezes and looks like this once MSLug gets loaded. I tried with 4 bit SD initially then backed off to original SPI mode but effect is the same. Using PSRAM timing same as edge but also tweaked up and down a few clocks without help.
It did load up once the very first time and let me get into the initial in-game MSlug menu and played sound fx etc but locked up just before it would have started actual gameplay when I wanted to start it.
Wondering if PSRAM settings might cause this, or actual overheating...?
Didn't you have a RAM test app that ran when the other Cogs were running sprite stuff at rated game clock speed? That could potentially be useful to debug this issue.
EDIT: wow the boards are HOT. Just took them out of the case to see how warm. Would be worth adding a thermocouple into the housing if I can fit it in while game is running. Even though my board is transferring some P2 heat too, I think an actual heatsink plate is going to be needed. Might also explain why it seemed to work the first time but not afterwards (once it had warmed up a lot). Also when I ran the memory test again now when things were warm I got worse values vs prior run.
@rogloh said:
@Wuerfel_21 I have ported your emulators to my updated HW and ran into some issue after loading screen. Screen changes and freezes and looks like this once MSLug gets loaded. I tried with 4 bit SD initially then backed off to original SPI mode but effect is the same. Using PSRAM timing same as edge but also tweaked up and down a few clocks without help.
You did try tweaking the sync/async settings, right?
It did load up once the very first time and let me get into the initial in-game MSlug menu and played sound fx etc but locked up just before it would have started actual gameplay when I wanted to start it.
Wondering if PSRAM settings might cause this, or actual overheating...?
Hard to decisively distinguish. But looks to me moreso like PSRAM fail rather than P2 core fail.
That the screen changes when trying to boot is normal, on startup the menu fix graphics are kicked out in favor of the game's fix graphics.
Didn't you have a RAM test app that ran when the other Cogs were running sprite stuff at rated game clock speed? That could potentially be useful to debug this issue.
yes. Will need to drop the customized NeoVGA into this.
Note that this doesn't just test PSRAM integrity, but is also really hard on the P2. If it doesn't run properly or locks up, that's a P2 core fault. Bad PSRAM only ever leads to red FAIL prints.
Comments
For reference this is the circuit I used for the SD on this board - it follows the same pin order as initially given in the SD card thread, although I didn't add the SD power LED to the 8th pin in this case as it is hidden inside the cartridge but I did include the general purpose LED on the 7th pin (also useful for debugging when standalone - eg. to find the xtal osc problem I had). Because I didn't have the power LED I just included a 1k8 to ground from the SD power supply to discharge the caps faster when the FET is turned off.
The V_USB and SENSE signals are not part of the SD stuff, they just happened to make use of a spare 22k resistor I had nearby for sensing 5V on the USB-C cable that can be optionally plugged-in.
Popcorn ready
Nice.
Discharge resistor isn't needed. The power LED stops conducting very early in discharge curve. The driver software pulls all the DAT and CMD pins low to drain caps. It takes about 37 28 milliseconds via the five 22 kR resistor paths.
PS: The level is monitored on the CLK pin so if it takes longer then no issue.
EDIT: Threshold is below 37 on 8-bit compDAC.
Actually, if you turn on -D SD_DEBUG it'll report how quickly the power-down happened.
Our external power feed resistor has now been cut and it runs the SD card test from inside the GPi case on it's internal Lipo powered 5V supply, with USB-C plugged directly into the cartridge. No more external supply shorting risk.
Now I just need to context switch back to messing with all the prior NeoYume settings etc - am a bit rusty for all that as it was several weeks ago now and I've been in HW mode since.
Just ran it again. But I see it did report some CMD10 errors before things ultimately worked, are they important?
( Entering terminal mode. Press Ctrl-] or Ctrl-Z to exit. )
clkfreq = 128000000 clkmode = 0x10001fb
SD card driver (4-bit SD mode) v1.12
sdsd_open: using pins: 53 52 48 55 54
Card detected ... power cycle of SD card
power-down threshold = 37 pin state = 1
power-down slope = 29633 us pin state = 0
SD clock-divider set to sysclock/320 (400 kHz)
Card idle OK
OCR register 80ff8000 - SDSC Card
Data Transfer Mode entered - Published RCA 1ff30000
CID register backed up
4-bit data interface engaged
Speed Class = C4 UHS Grade = U0
Video Class = V0 App Class = A0
Cache = 0 Queue = 0
TRIM = 0 FULE = 0
Card User Capacity = 1920 MB (1.88 GB)
High-Speed access mode engaged
SD clock-divider set to sysclock/4 (32.0 MHz)
. CMD10 error!
. CMD10 error!
. CMD10 error!
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
. CMD10 error!
. CMD10 error!
. CMD10 error!
. CMD10 error!
. CMD10 error!
. CMD10 error!
. CMD10 error!
. CMD10 error!
. CMD10 error!
. CMD10 error!
. CMD10 error!
. CMD10 error!
. CMD10 error!
rxlag=8 selected Lowest=4 Highest=11
CID decode: ManID=02 OEMID=TM Name=SD02G
Ver=3.2 Serial=a8ab6696 Date=2008-4
SD Card Init Successful
/sd1 handle = 105f0 ... mounted
Delete 100 files ... Duration 1197 ms, 83.5 files/s
File size = 512 bytes
Create 100 files ... Duration 3964 ms, 25.2 files/s
Verify 100 files ... Duration 357 ms, 280.1 files/s
Clean-up ... errno = 0: OK
Thanks. Those errors are complete normal, it's the calibration routine making use of the regular command/response functions to find the good/bad boundaries of rxlag setting.
@Wuerfel_21 I have ported your emulators to my updated HW and ran into some issue after loading screen. Screen changes and freezes and looks like this once MSLug gets loaded. I tried with 4 bit SD initially then backed off to original SPI mode but effect is the same. Using PSRAM timing same as edge but also tweaked up and down a few clocks without help.
It did load up once the very first time and let me get into the initial in-game MSlug menu and played sound fx etc but locked up just before it would have started actual gameplay when I wanted to start it.
Wondering if PSRAM settings might cause this, or actual overheating...?
Didn't you have a RAM test app that ran when the other Cogs were running sprite stuff at rated game clock speed? That could potentially be useful to debug this issue.
EDIT: wow the boards are HOT. Just took them out of the case to see how warm. Would be worth adding a thermocouple into the housing if I can fit it in while game is running. Even though my board is transferring some P2 heat too, I think an actual heatsink plate is going to be needed.
Might also explain why it seemed to work the first time but not afterwards (once it had warmed up a lot). Also when I ran the memory test again now when things were warm I got worse values vs prior run.
I can actually run it with the cartridge opened so it can be probed.
You did try tweaking the sync/async settings, right?
Hard to decisively distinguish. But looks to me moreso like PSRAM fail rather than P2 core fail.
That the screen changes when trying to boot is normal, on startup the menu fix graphics are kicked out in favor of the game's fix graphics.
yes. Will need to drop the customized NeoVGA into this.
Note that this doesn't just test PSRAM integrity, but is also really hard on the P2. If it doesn't run properly or locks up, that's a P2 core fault. Bad PSRAM only ever leads to red FAIL prints.
And now a whole other hand-warmer engineering exercise begins.