@evanh said:
... Where does Catalina hubRAM use start at?
Just looking at the .lst file and it looks like the answer is $1000 (4 kB). Everything before that looks to be cog0 cogRAM.
Yes, that's usually the case. However, I have a vague memory of using a 256 byte buffer in that low RAM area for something - either in another plugin, or perhaps for loading XMM programs^ - which is so complex it makes my brain hurt just at the thought of having to revisit it
But you should be fine to use it in this case for debugging.
Ross.
^ EDIT: Did a quick search, and couldn't find anything like this. It may have been something I later decided to remove.
Thanks. I've started poking but nothing strongly stood out. The init is completing without error. The CID and CSD do get a different set of numbers but aren't gibberish. Haven't worked out why as yet.
I've made a bit of a mess of the driver so might start over.
@evanh said:
I've made a bit of a mess of the driver so might start over.
Thanks for the efforts. You may be interested to know I have recompiled all Catalyst programs (including Catalina itself) to run at 300Mh using my driver with an SD card delay of zero, and have been doing extensive testing of Cake with it, which (amongst other things) means doing lots of test compilations on the Propeller 2 itself. And I have not seen any SD card lockups since the first few instances.
This is the problem I always seem to have with SD cards - they can work flawlessly for a long time, but occasionally they fail for no apparent reason. I have often wondered if it is the P2 SD circuitry itself, which shares pins between FLASH and SD, and even thought the flash is disabled when the SD card is in use, there may be an issue there - something which your experiences when using different pins for the SD card might also point to - but I am not hardware-savvy enough to really say, and nor do I have the tools to see what's happening at the hardware level
The SD/Flash sharing arrangement is pretty bad. It causes strange issues for everyone. It appears most people building custom boards with SD card slots are going for separate pins or 4bit i/f now, at the expense of SD boot.
@Wuerfel_21 said:
The SD/Flash sharing arrangement is pretty bad. It causes strange issues for everyone. It appears most people building custom boards with SD card slots are going for separate pins or 4bit i/f now, at the expense of SD boot.
I only have P2 Edge and P2 Eval boards, but Catalyst can be booted from FLASH instead of from the SD^ - I will try that configuration for a while and see if it makes a difference.
^ To boot Catalyst from FLASH (but also still use the SD card) you set the FLASH switch to ON and the P59^ & P59v switches both OFF. Insert the SD card, but then use flash_payload. For example: flash_payload catalyst.bin -i
More details in the Flash Support section of the Catalina Compiler Reference Manual for the Propeller 2
@evanh said:
Thanks. I've started poking but nothing strongly stood out.
Ahhh, I've struck this before. Many SD cards have an internal pull-up on the DO pin, but some don't. Or maybe none do, dunno. At any rate, there is a specific active pull-up in my edited version of the sdmm built-in driver in Flexspin. I keep forgetting it has that. The 4-bit SD mode driver doesn't need it because the add-on board has pull-up resistors on every pin.
When I'm testing non-boot pins I'm using the 4-bit add-on board with the wired pull-up resistors, making the issue go away.
@evanh said:
At any rate, there is a specific active pull-up in my edited version of the sdmm built-in driver in Flexspin.
I don't understand this bit. How do you implement the pull-up in software?
Configure the output drive to 15K ohms, then drive it high. Or better still, DRVL and use the invert pin drive. Then it happily acts as an input with a pull-up.
Right, good reminder, I gotta get motivated to see if it solves everything or not ...
Hmm, I've just realised I'm getting the identical behaviour with Flexspin's sdmm driver too. It's only happening with one of my uSD cards (Sandisk Extreme 64 GB, dated 2024) and only on the boot pins. Put that same card in the 4-bit add-on slot and no problem with it either. Same for both Flexspin and Catalina compiled programs. The pull-up on DO doesn't appear to be the issue, although without it sdmm can't init any SD card.
Specifically, on every second init sequence the 64 GB SD card is reporting from CMD58 as byte addressable SDSC, and only 30 MB capacity reported in CSD register (CMD9). The card seems to change config somehow. And has probably always done this but I only just noticed first when testing with Catalina.
Solved. I've moved R802 to R801 position on the Eval Board, permanently enabling the voltage regular that powers the boot SD slot and Flash EEPROM. This prevents the reset circuit from power cycling these parts.
PS: I now see another reason I'd hadn't been seeing this earlier. The older Eval Board I have, which is the one I've done most testing with, I'd already moved R802 long ago.
Ross,
There's a chance your random file corruption could be because of this same poor power cycling - Which occurs on each download. I recommend making the wiring change just to take the possibility off the table.
@evanh said:
Ross,
There's a chance your random file corruption could be because of this same poor power cycling - Which occurs on each download. I recommend making the wiring change just to take the possibility off the table.
Sadly, I don't have the tools to do it even if I had the eyesight. Also, what would be the equivalent on a P2 Edge board?
@RossH said:
... Also, what would be the equivalent on a P2 Edge board?
Ah, it doesn't do the power cycle on reset at all. The SD slot and Flash EEPROM both are supplied direct from the V5663 LDO regulator, whcih in turn comes straight off the common 3.8V switching regulator. Okay, sounds you're getting the identical behaviour on both Eval and Edge. Which then means you're dealing with a different issue than me.
PS: It's the same for most of the EC and EC32MB revisions. The original EC rev A uses a diode drop from 5 Volts instead of the switching regulator for the common to the LDOs but otherwise is the same.
Comments
Just looking at the .lst file and it looks like the answer is $1000 (4 kB). Everything before that looks to be cog0 cogRAM.
Yes, that's usually the case. However, I have a vague memory of using a 256 byte buffer in that low RAM area for something - either in another plugin, or perhaps for loading XMM programs^ - which is so complex it makes my brain hurt just at the thought of having to revisit it
But you should be fine to use it in this case for debugging.
Ross.
^ EDIT: Did a quick search, and couldn't find anything like this. It may have been something I later decided to remove.
Thanks. I've started poking but nothing strongly stood out. The init is completing without error. The CID and CSD do get a different set of numbers but aren't gibberish. Haven't worked out why as yet.
I've made a bit of a mess of the driver so might start over.
Thanks for the efforts. You may be interested to know I have recompiled all Catalyst programs (including Catalina itself) to run at 300Mh using my driver with an SD card delay of zero, and have been doing extensive testing of Cake with it, which (amongst other things) means doing lots of test compilations on the Propeller 2 itself. And I have not seen any SD card lockups since the first few instances.
This is the problem I always seem to have with SD cards - they can work flawlessly for a long time, but occasionally they fail for no apparent reason. I have often wondered if it is the P2 SD circuitry itself, which shares pins between FLASH and SD, and even thought the flash is disabled when the SD card is in use, there may be an issue there - something which your experiences when using different pins for the SD card might also point to - but I am not hardware-savvy enough to really say, and nor do I have the tools to see what's happening at the hardware level
Ross.
The SD/Flash sharing arrangement is pretty bad. It causes strange issues for everyone. It appears most people building custom boards with SD card slots are going for separate pins or 4bit i/f now, at the expense of SD boot.
I only have P2 Edge and P2 Eval boards, but Catalyst can be booted from FLASH instead of from the SD^ - I will try that configuration for a while and see if it makes a difference.
^ To boot Catalyst from FLASH (but also still use the SD card) you set the FLASH switch to ON and the P59^ & P59v switches both OFF. Insert the SD card, but then use flash_payload. For example:
flash_payload catalyst.bin -iMore details in the Flash Support section of the Catalina Compiler Reference Manual for the Propeller 2
Ahhh, I've struck this before. Many SD cards have an internal pull-up on the DO pin, but some don't. Or maybe none do, dunno. At any rate, there is a specific active pull-up in my edited version of the sdmm built-in driver in Flexspin. I keep forgetting it has that. The 4-bit SD mode driver doesn't need it because the add-on board has pull-up resistors on every pin.
When I'm testing non-boot pins I'm using the 4-bit add-on board with the wired pull-up resistors, making the issue go away.
...
I don't understand this bit. How do you implement the pull-up in software?
Configure the output drive to 15K ohms, then drive it high. Or better still, DRVL and use the invert pin drive. Then it happily acts as an input with a pull-up.
Right, good reminder, I gotta get motivated to see if it solves everything or not ...
Hmm, I've just realised I'm getting the identical behaviour with Flexspin's sdmm driver too. It's only happening with one of my uSD cards (Sandisk Extreme 64 GB, dated 2024) and only on the boot pins. Put that same card in the 4-bit add-on slot and no problem with it either. Same for both Flexspin and Catalina compiled programs. The pull-up on DO doesn't appear to be the issue, although without it sdmm can't init any SD card.
Specifically, on every second init sequence the 64 GB SD card is reporting from CMD58 as byte addressable SDSC, and only 30 MB capacity reported in CSD register (CMD9). The card seems to change config somehow. And has probably always done this but I only just noticed first when testing with Catalina.
Scratching my head a little here.
Solved. I've moved R802 to R801 position on the Eval Board, permanently enabling the voltage regular that powers the boot SD slot and Flash EEPROM. This prevents the reset circuit from power cycling these parts.
Here's the supply volts for the power cycle that succeeds in resetting that SD card:
And the one that doesn't succeed:
Neither of them are even close to achieving the SD spec for power cycling. Which is to fall below 0.5 Volt for at least 1.0 millisecond.
PS: I now see another reason I'd hadn't been seeing this earlier. The older Eval Board I have, which is the one I've done most testing with, I'd already moved R802 long ago.
Ross,
There's a chance your random file corruption could be because of this same poor power cycling - Which occurs on each download. I recommend making the wiring change just to take the possibility off the table.
Sadly, I don't have the tools to do it even if I had the eyesight. Also, what would be the equivalent on a P2 Edge board?
Ross.
Ah, it doesn't do the power cycle on reset at all. The SD slot and Flash EEPROM both are supplied direct from the V5663 LDO regulator, whcih in turn comes straight off the common 3.8V switching regulator. Okay, sounds you're getting the identical behaviour on both Eval and Edge. Which then means you're dealing with a different issue than me.
PS: It's the same for most of the EC and EC32MB revisions. The original EC rev A uses a diode drop from 5 Volts instead of the switching regulator for the common to the LDOs but otherwise is the same.