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.
@rogloh said:
EDIT: ... I think an actual heatsink plate is going to be needed.
And now a whole other hand-warmer engineering exercise begins.
If a suitable part is modelled, we could potentially then create a 3d printed metal backshell in the same profile as the plastic (or squeezes just under the existing plastic) and contacts the P2 - this would give a large surface area to spread/radiate the heat. But whether stainless steel is as good enough a heat conductor vs Al or Cu not sure.
Existing cartridge shell looks like this inside. There's probably a 2-3 mm gap above the components on Lachlan's P2 board to the back surface, so enough room for a custom metal plate. It could also go though to the outside of the plastic at the back with fins in the worst case. But ideally it could retain the same external size for a cleaner look.
@Wuerfel_21 said:
You did try tweaking the sync/async settings, right?
Yeah, tried a few combos but was not exhaustive at every single nearby delay step - could retry again.
@rogloh said:
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.
Ran MSlug with the back open for over 8mins before it locked up. Temp started out at ambient 19C and then rose to ~64C on the hottest part detected by my infrared thermometer when pointing towards the P2. I think this is probably a thermal issue. I might try blowing air on it while playing and see how it behaves and whether it lasts even longer before failing, if it even does fail with that. I could also try to add a heatsink from a RasPi kit or similar as another test.
This test was run with the slow PSRAM clock enabled (sysclk/3) and a 16 clock delay according to these config.spin2 settings.
@rogloh said:
EDIT: ... I think an actual heatsink plate is going to be needed.
And now a whole other hand-warmer engineering exercise begins.
If a suitable part is modelled, we could potentially then create a 3d printed metal backshell in the same profile as the plastic (or squeezes just under the existing plastic) and contacts the P2 - this would give a large surface area to spread/radiate the heat. But whether stainless steel is as good enough a heat conductor vs Al or Cu not sure.
Aluminium is the way. Cheap, easy to work, lightest weight of the three, and does a good job as a heatsink. Anodise it for looks and wear resistance, then maybe add plastic handles or similar where it gets a lot of wear.
So I went and quickly purchased a 14x14 mm stick on heatsink and ran with that (back open) and I played for 30mins then I stopped without crashing. Heat reached about 58C on the back of the P2 according to my thermometer which is 5C less than the crash point, although this was with 19C ambient so room temp of 25C may still fail.
At least this shows a marked improvement and it would appear overheating is the prime issue to resolve. A custom heatsink case or insert would be nice to sort out and 3d print.
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.
If a suitable part is modelled, we could potentially then create a 3d printed metal backshell in the same profile as the plastic (or squeezes just under the existing plastic) and contacts the P2 - this would give a large surface area to spread/radiate the heat. But whether stainless steel is as good enough a heat conductor vs Al or Cu not sure.
Existing cartridge shell looks like this inside. There's probably a 2-3 mm gap above the components on Lachlan's P2 board to the back surface, so enough room for a custom metal plate. It could also go though to the outside of the plastic at the back with fins in the worst case. But ideally it could retain the same external size for a cleaner look.
Yeah, tried a few combos but was not exhaustive at every single nearby delay step - could retry again.
Thanks for this, I'll try it today.
Ran MSlug with the back open for over 8mins before it locked up. Temp started out at ambient 19C and then rose to ~64C on the hottest part detected by my infrared thermometer when pointing towards the P2. I think this is probably a thermal issue. I might try blowing air on it while playing and see how it behaves and whether it lasts even longer before failing, if it even does fail with that. I could also try to add a heatsink from a RasPi kit or similar as another test.
This test was run with the slow PSRAM clock enabled (sysclk/3) and a 16 clock delay according to these config.spin2 settings.
Aluminium is the way. Cheap, easy to work, lightest weight of the three, and does a good job as a heatsink. Anodise it for looks and wear resistance, then maybe add plastic handles or similar where it gets a lot of wear.
So I went and quickly purchased a 14x14 mm stick on heatsink and ran with that (back open) and I played for 30mins then I stopped without crashing. Heat reached about 58C on the back of the P2 according to my thermometer which is 5C less than the crash point, although this was with 19C ambient so room temp of 25C may still fail.
At least this shows a marked improvement and it would appear overheating is the prime issue to resolve. A custom heatsink case or insert would be nice to sort out and 3d print.
Roger.
Few other pics...there's just a 2mm gap between the FireAnt board and Lachlan's P2 board.
