I'm not saying that what Tubular is saying the same thing, but my experience with the P1 and SD cards was sometimes the card would get "stuck" because there was some leakage power still flowing into the card from USB.
Only by completely removing power (pulling the card or unplugging all power sources) did the card then respond to commands.
I vaguely remember there was some kind of initialization clocking sequence to get the card to a known state? What if the card just isn't ready yet, and the unlocking clocking needs to be attempted multiple times if it isn't sending the right response? Is there code for multiple attempts after a reasonable delay?
One thing that is important is to use the PNut_v32 for compiling the boot ROM if you're going to run it on the P2 Eval board with the ES silicon.
New booter code must be assembled using PNut_33j, in order to work on the latest FPGA images. There are encoding differences in the hub memory instructions, as well as the LUT instructions.
P2-EVAL: I have been using the P59 pullup switch on (2nd from end). This prevents the SD from being accessed in the existing ROM code. Now I can download fresh ROM code such as the 002d or 002f posted here. This will give me some debug info if it fails.
The 002f code has more debugging but doesnt get past cmd8 but i didnt output the reply from the sd
I havent beennable to get the latest TAQOZ to stop outputting messages so i can see if there is anything different or other debug info.
My SanDisk Ultras (16GB & 64GB) work fine for me.
I wonder if those long traces and the caps on the SD pins are upsetting things on the P2-EVAL boards??? even tho they work for me.
A thought - On my P1 boards the traces are extremely short and right at the socket I have a 100nF and 10uF smt across the power and gnd pins. This is a requirement due to the power surges required by the cards. Ive not had any problems with SD cards although in the early days lots of problems had been reported so i always recommended SanDisk.
BTW once a card is locked-up with some problem, it seems only a power removal will get it out of lockup. It is difficult to get to the socket on the P2D2 board with power on
One thing that is important is to use the PNut_v32 for compiling the boot ROM if you're going to run it on the P2 Eval board with the ES silicon.
New booter code must be assembled using PNut_33j, in order to work on the latest FPGA images. There are encoding differences in the hub memory instructions, as well as the LUT instructions.
For the P2Eval board p2asm and fastspin should work as well as PNut_V32 (I know fastspin can compile the boot ROM, I've tried it).
But for the FPGA, PNut_33j is the only game in town right now.
My P2-ES seems to be allergic to some uSD cards.
The two cards I have (Team 8GB and Sandisk 32GB) don't even get out the starting blocks.
Both cards prevent Pnut from identifying (Ctrl-G) the Prop2, so forget about loading test code.
Scope shows all voltage rails to be Ok, no spikes.
Two other cards that work in Tubular's P2-ES work fine though, so uSD card circuit is fine.
That provides a nice way to sabotage any P2 system then...
How is that possible tho, does that mean some skewed loading on the pins, that takes P2 into some boot-tree decision blindspot ?
I'm not saying that what Tubular is saying the same thing, but my experience with the P1 and SD cards was sometimes the card would get "stuck" because there was some leakage power still flowing into the card from USB.
Only by completely removing power (pulling the card or unplugging all power sources) did the card then respond to commands.
I vaguely remember there was some kind of initialization clocking sequence to get the card to a known state? What if the card just isn't ready yet, and the unlocking clocking needs to be attempted multiple times if it isn't sending the right response? Is there code for multiple attempts after a reasonable delay?
Yes. some silicon is quite able to keep states, down to way under 1V.
Hidden in the specs you can often find the POR recovery voltage, that Vdd that it must go below, in order for the next power-on-reset to properly behave. Some also have dV/dT limits.
IIRC I've seen as low as < 200mV spec'd on some MCUs, so total physical removal is one way to ensure you have no residual voltages.
I havent beennable to get the latest TAQOZ to stop outputting messages so i can see if there is anything different or other debug info.
My SanDisk Ultras (16GB & 64GB) work fine for me.
I've seen the repeating message thing with the Samsung 64 GB SDXC (Exfat Initially). Fwiw i just typed "0 FORMAT" which (at end of line) stopped the rolling messages, completed the FAT32 format, and was able to run the new Taqoz rom.
So Cluso I'm curious about these 16GB Sandisk Ultra's that work for you, abort after command 8 for me, and bring OzProp's board to a freeze. Think I'm going to buy a fresh one and see whether I can get it to work like I could with the 32GB Sandisk Ultra, brand new from shop.
I wonder whether what both my 16 GB's have been used for previously (recording camera) has had some effect, if so we can chase down what's different in the MBR
Ok happy to report a freshly bought same SanDisk Ultra 16GB works fine. We can follow up why the other two don't work later, but it may have to do with their prior use in a recording camera.
I'll express post this working card over to you OzProp, hopefully it will 'just work' in your board
Switched p59^ on.
Compiled & Ran rombooter.spin2 from spin2gui (after setting configure run command terminal baud to 115200).
Got the attached output (summarized here)
Courier just left here with 2 tested working SD cards
- a 16 GB Sandisk Ultra SDHC, and
- a Samsung 64GB SDXC which has been formatted by Taqoz
If you have trouble, try pulling the SDxC card out, putting it back in, then hit "propeller reset" button. Taqoz should appear fairly quickly - within a second or two
I'm going to pick up a couple more widely available sdxc's - team, verbatim/imation and give them a quick try.
Taking a cheese break from testing and updating the ROM. The thing is with all these low level tests going on, I'd like to know if they do exactly the same in TAQOZ V2 if only somebody will do a loadp2 of the image and maybe even check formatting of 64GB cards. I'm still waiting to hear back over on the TAQOZ forum, so far, not a thing...
Taking a cheese break from testing and updating the ROM. The thing is with all these low level tests going on, I'd like to know if they do exactly the same in TAQOZ V2 if only somebody will do a loadp2 of the image and maybe even check formatting of 64GB cards. I'm still waiting to hear back over on the TAQOZ forum, so far, not a thing...
Sorry Peter I did post in this thread about success with "0 FORMAT" on a Samsung 64 GB SDXC card, but probably wasn't verbose enough about it.
Previously it was exFat and, when inserted, Taqoz repeated a one liner reporting the card type and some parameters over and over. I just typed '0 FORMAT' anyway, then at the end of that line the spining line of formatting took over from the scrolling lines. After that fat32 format I was able to successfully place a bootup image in its root directory, and P2-Eval does boot from this successfully.
Also when inserted Taqoz now outputs a single status line, rather than a repeating stream.
The ROM code has gone to Chip with TAQOZ and a last minute timeout bug fix in my SD routine. I was running a test sequentially reading each sector on the exFAT 64GB card and it would fail just over $4000 Sectors
Okay! Peter Jakacki and Cluso99 stayed up really late in Australia and I stayed up all night, in order to get the ROM finalized.
I just sent it off to ON Semi.
We all did our testing, but it would be good to exercise it some more over the next few days, in order to uncover any latent bugs that might exist. I will make new FPGA files for this purpose. It looks good, anyway.
I nearly found the way to put exFAT into the SD Boot. I've located the VOL & DIR but not yet found how to calculate the files first sector tho I know its size and location. But that found me a timeout bug so I'll post the solution in the Tricks & Traps thread shortly.
Out of interest is there any instruction set incompatibility between the new vs old code? Ie can we run the new ROM on the existing P2 Silicon? Or will we need to go back to fpgas to run the new rom?
Out of interest is there any instruction set incompatibility between the new vs old code? Ie can we run the new ROM on the existing P2 Silicon? Or will we need to go back to fpgas to run the new rom?
* Chip's Booter did not change
* SD Booter has some minor changes/fixes but not impacted by new silicon
* Monitor/Debugger did not change (same call locations)
* TAQOZ changed but tested on current silicon & new FPGA
Out of interest is there any instruction set incompatibility between the new vs old code? Ie can we run the new ROM on the existing P2 Silicon? Or will we need to go back to fpgas to run the new rom?
The ROM must come up on reset each time and the silicon's ROM cannot be overridden.
There are also assembler encoding differences in the RDxxxx/WRxxxx instructions for hub and LUT. It could be assembled, though, using the silicon-compatible PNut and then downloaded, and talked to if reset was avoided.
There are also assembler encoding differences in the RDxxxx/WRxxxx instructions for hub and LUT. It could be assembled, though, using the silicon-compatible PNut and then downloaded, and talked to if reset was avoided.
Pity they could not be superset compatible.
Being non-binary compatible means users of the existing P2-Evals will need a P2/P2+ target switch, and you need to be absolutely certain the submitted ROM code is the 'right' build.
Can P2/P2+ tell which one they are - ie can code check the version ?
Can the source (pragma style) over-rule any command line, so a ROM file targeting P2+, can only ever create P2+ binaries ?
There are also assembler encoding differences in the RDxxxx/WRxxxx instructions for hub and LUT. It could be assembled, though, using the silicon-compatible PNut and then downloaded, and talked to if reset was avoided.
Pity they could not be superset compatible.
Being non-binary compatible means users of the existing P2-Evals will need a P2/P2+ target switch, and you need to be absolutely certain the submitted ROM code is the 'right' build.
Can P2/P2+ tell which one they are - ie can code check the version ?
Can the source (pragma style) over-rule any command line, so a ROM file targeting P2+, can only ever create P2+ binaries ?
The new silicon will report "G" as its version. The new silicon FPGA images use the same scheme as they have all along, where "A" is an A9, etc. It will be important to use the v32 assember encoding for the P2-Eval boards.
A chip could figure out what version it is by doing a 'BITH reg,#1<<5 + 0' and checking if one (v32) or two (v33) LSBs were set in reg. Tools may need a switch for a while. After P2+ comes out, with only 120 chips out in the world, tools can focus exclusively on P2+. We'll have a few months of crossover time.
OzProp and I have been testing SDHC and SDXC cards and boot operation, including bringing Flash into the mix. Oz has put your SD debug 002h into flash so we can see whats happening along the way
We're at the point where booting once from a SDHC or SDXC card seems good and reliable, and the "0 FORMAT" fat32 format in Taqoz works great, so thanks for your efforts. However when we try repeated boots (pressing the reset key over and over), we encounter some issues as described below
We have these cards
- SanDisk Ultra 16 & 32 GB SDHC (Red and Grey, from Officeworks)
- Samsung 64 GB SDHC (Orange and White, from MMT)
- also some others - Toshiba (from BigW), Team (from MMT), which we'll test later today
For the SanDisk,
- Without the flash enabled, the SanDisk is fine with multiple boots. ie this case seems to be 'working', and I think this is what you're testing too
- With the flash enabled by dip switch, the SanDisk bombs out after command 8 in Cluso's code on the second and subsequent boots. This implies the card is retaining some state between between boots (ie not fully resetting). The failure message on second and subsequent is as follows
For the Samsung,
- Without the flash enabled, Taqoz boots the first time, only.
- With the flash enabled, Cluso's code from flash runs first time only, followed by Taqoz (once), but subsequent boots do nothing (not even get into flash code again).
Note that this implies the SD card state is not only requiring full power down/removal to recover, as previously outlined, but is worse because its preventing flash operation and recovery.
We tried resetting mid Cluso SD debug code and got the same results, which makes me think we can just focus on Cluso's SD code for now. We have a couple of these Samsung cards, and I can get more and send to you if you like Cluso, Peter. They are $19 and coming down fast so I think these will be pretty common by the time P2 gets out later this year
Sorry to not find this out earlier... and I reiterate that your efforts are much appreciated.
Comments
Only by completely removing power (pulling the card or unplugging all power sources) did the card then respond to commands.
I vaguely remember there was some kind of initialization clocking sequence to get the card to a known state? What if the card just isn't ready yet, and the unlocking clocking needs to be attempted multiple times if it isn't sending the right response? Is there code for multiple attempts after a reasonable delay?
New booter code must be assembled using PNut_33j, in order to work on the latest FPGA images. There are encoding differences in the hub memory instructions, as well as the LUT instructions.
The 002f code has more debugging but doesnt get past cmd8 but i didnt output the reply from the sd
I havent beennable to get the latest TAQOZ to stop outputting messages so i can see if there is anything different or other debug info.
My SanDisk Ultras (16GB & 64GB) work fine for me.
I wonder if those long traces and the caps on the SD pins are upsetting things on the P2-EVAL boards??? even tho they work for me.
A thought - On my P1 boards the traces are extremely short and right at the socket I have a 100nF and 10uF smt across the power and gnd pins. This is a requirement due to the power surges required by the cards. Ive not had any problems with SD cards although in the early days lots of problems had been reported so i always recommended SanDisk.
BTW once a card is locked-up with some problem, it seems only a power removal will get it out of lockup. It is difficult to get to the socket on the P2D2 board with power on
For the P2Eval board p2asm and fastspin should work as well as PNut_V32 (I know fastspin can compile the boot ROM, I've tried it).
But for the FPGA, PNut_33j is the only game in town right now.
How is that possible tho, does that mean some skewed loading on the pins, that takes P2 into some boot-tree decision blindspot ?
Did you check those with card removal / replace ?
Yes. some silicon is quite able to keep states, down to way under 1V.
Hidden in the specs you can often find the POR recovery voltage, that Vdd that it must go below, in order for the next power-on-reset to properly behave. Some also have dV/dT limits.
IIRC I've seen as low as < 200mV spec'd on some MCUs, so total physical removal is one way to ensure you have no residual voltages.
I've seen the repeating message thing with the Samsung 64 GB SDXC (Exfat Initially). Fwiw i just typed "0 FORMAT" which (at end of line) stopped the rolling messages, completed the FAT32 format, and was able to run the new Taqoz rom.
I wonder whether what both my 16 GB's have been used for previously (recording camera) has had some effect, if so we can chase down what's different in the MBR
I'll express post this working card over to you OzProp, hopefully it will 'just work' in your board
Initial power up: set P59 switch off, >space esc to TAQOZ. Mount. Reset P2ES. TAQOZ reports: Switched p59^ on.
Compiled & Ran rombooter.spin2 from spin2gui (after setting configure run command terminal baud to 115200).
Got the attached output (summarized here)
Tom
- a 16 GB Sandisk Ultra SDHC, and
- a Samsung 64GB SDXC which has been formatted by Taqoz
If you have trouble, try pulling the SDxC card out, putting it back in, then hit "propeller reset" button. Taqoz should appear fairly quickly - within a second or two
I'm going to pick up a couple more widely available sdxc's - team, verbatim/imation and give them a quick try.
Did you try the older version 002d ? I want to ensure I haven't introduced a bug.
I will be home maybe around 5pm, and I'll post an update with more debug info from cmd8.
Here is v002g with more debugging.
I am particularly interested in failed cards other than those reporting
i) ptn type $06
or
i) ptn type $07
Type $06 are FAT16 and $07 are exFAT or NTFS which are not suported except via MBR booting.
Where is v002g?
Minor tweek for Chip - doesnt check pullup when jumped to from Chips booter as its already tested
Sorry Peter I did post in this thread about success with "0 FORMAT" on a Samsung 64 GB SDXC card, but probably wasn't verbose enough about it.
Previously it was exFat and, when inserted, Taqoz repeated a one liner reporting the card type and some parameters over and over. I just typed '0 FORMAT' anyway, then at the end of that line the spining line of formatting took over from the scrolling lines. After that fat32 format I was able to successfully place a bootup image in its root directory, and P2-Eval does boot from this successfully.
Also when inserted Taqoz now outputs a single status line, rather than a repeating stream.
I just sent it off to ON Semi.
We all did our testing, but it would be good to exercise it some more over the next few days, in order to uncover any latent bugs that might exist. I will make new FPGA files for this purpose. It looks good, anyway.
Here is the ROM code for v2 silicon:
Stellar effort all round.
Thank you for never giving up hope!
FWIW I am gathering up some more brands of cards to give a quick test tomorrow.
There are others helping with the P2 too!
I nearly found the way to put exFAT into the SD Boot. I've located the VOL & DIR but not yet found how to calculate the files first sector tho I know its size and location. But that found me a timeout bug so I'll post the solution in the Tricks & Traps thread shortly.
* Chip's Booter did not change
* SD Booter has some minor changes/fixes but not impacted by new silicon
* Monitor/Debugger did not change (same call locations)
* TAQOZ changed but tested on current silicon & new FPGA
The ROM must come up on reset each time and the silicon's ROM cannot be overridden.
There are also assembler encoding differences in the RDxxxx/WRxxxx instructions for hub and LUT. It could be assembled, though, using the silicon-compatible PNut and then downloaded, and talked to if reset was avoided.
Pity they could not be superset compatible.
Being non-binary compatible means users of the existing P2-Evals will need a P2/P2+ target switch, and you need to be absolutely certain the submitted ROM code is the 'right' build.
Can P2/P2+ tell which one they are - ie can code check the version ?
Can the source (pragma style) over-rule any command line, so a ROM file targeting P2+, can only ever create P2+ binaries ?
The new silicon will report "G" as its version. The new silicon FPGA images use the same scheme as they have all along, where "A" is an A9, etc. It will be important to use the v32 assember encoding for the P2-Eval boards.
A chip could figure out what version it is by doing a 'BITH reg,#1<<5 + 0' and checking if one (v32) or two (v33) LSBs were set in reg. Tools may need a switch for a while. After P2+ comes out, with only 120 chips out in the world, tools can focus exclusively on P2+. We'll have a few months of crossover time.
OzProp and I have been testing SDHC and SDXC cards and boot operation, including bringing Flash into the mix. Oz has put your SD debug 002h into flash so we can see whats happening along the way
We're at the point where booting once from a SDHC or SDXC card seems good and reliable, and the "0 FORMAT" fat32 format in Taqoz works great, so thanks for your efforts. However when we try repeated boots (pressing the reset key over and over), we encounter some issues as described below
We have these cards
- SanDisk Ultra 16 & 32 GB SDHC (Red and Grey, from Officeworks)
- Samsung 64 GB SDHC (Orange and White, from MMT)
- also some others - Toshiba (from BigW), Team (from MMT), which we'll test later today
For the SanDisk,
- Without the flash enabled, the SanDisk is fine with multiple boots. ie this case seems to be 'working', and I think this is what you're testing too
- With the flash enabled by dip switch, the SanDisk bombs out after command 8 in Cluso's code on the second and subsequent boots. This implies the card is retaining some state between between boots (ie not fully resetting). The failure message on second and subsequent is as follows
For the Samsung,
- Without the flash enabled, Taqoz boots the first time, only.
- With the flash enabled, Cluso's code from flash runs first time only, followed by Taqoz (once), but subsequent boots do nothing (not even get into flash code again).
Note that this implies the SD card state is not only requiring full power down/removal to recover, as previously outlined, but is worse because its preventing flash operation and recovery.
We tried resetting mid Cluso SD debug code and got the same results, which makes me think we can just focus on Cluso's SD code for now. We have a couple of these Samsung cards, and I can get more and send to you if you like Cluso, Peter. They are $19 and coming down fast so I think these will be pretty common by the time P2 gets out later this year
Sorry to not find this out earlier... and I reiterate that your efforts are much appreciated.