Issues while booting from a micro SD card
mccarthr
Posts: 6
Hello!
This is my first post on the forms, I have been using the propeller 2 on a custom board for about 8 months now using flexcc to compile my C code. Recently I have been attempting to boot the propeller from an SD card using the standard pins and layout shown in the Datasheet (P58-P61). Unfortunately, while I am able to mount this SD card using the mount functionality in flexprop and TAQOZ the propeller seems like it won't enter SD boot mode and the only way I can run code is using a USB serial connection.
Setup:
- I have a fat32 formatted sd with a file in the root named "_P2_BOOT.BIX".
- SD card connected to P58-61 with no pullup resistors (according to the documentation the SD card has the required pull-ups to enable SD boot mode)
I have been able to load the binary file using P2 ROM Monitor using the command "R_P2_BOOT.BIX". It seems like the SD card and propeller are communicating properly and the binary file is able to execute using this method, so I think my issue is with putting the prop into sd boot mode.
I appreciate any help or insight anyone can offer!
Thanks,
Riley
Comments
There's been some reports of issues with the SD bootloader, IIRC. Is the card freshly formatted? If not, give that a try.
Interesting, I have tried 2 different sd cards both freshly formatted. Has there been any talk about quick fixes like reflashing the bootloader?
The most common problem people run into is stopping the SD card from booting when trying to use serial boot. The ROM boot sequence gives priority to the SD card if it is bootable.
However, a pull-up on P59 will bypass SD booting and just wait for serial only.
It is strange that I'm having the opposite problem, is there another test I can run to try and figure out the issue? I thought it might be my circuit layout but being able to run the binary using ROM monitor with the bootable filename makes me think otherwise.
Also thanks for the tip on using the pulldown resistor, once I get booting from SD that will be very helpful.
If there is a pull-up on P61 then that'll prevent SD booting too.
Using the table I tried putting a pull-down resistor on P59 so it will use SD card only which definitely disabled serial boot but still did not run the binary. I also tried a physical pullup on P60 but still nothing. Any ideas for the next steps/tests? with my limited knowledge, I cannot think of anything else to do.
Here's a blurb from Cluso's write-up of his ROM code:
Further reading - https://forums.parallax.com/discussion/170637/p2-sd-boot-code-rev-2-silicon/p1
If you can still get them, it's worth using the Red & Grey sandisk microsd cards that Cluso used during his testing.
See page 30 of my Taqoz glossary - this worked for me. Sadly, not all card types bought on the high street work and not all formatting modes are supported.
DOH! Riley, I just saw it now. I'd checked it earlier but hadn't even noticed the transposition then .... Your file name is _P2_BOOT.BIX ... but should be _BOOT_P2.BIX
I was using the information located in the Micro SD Boot in the documentation: https://docs.google.com/document/d/12wyP2QZUxywYQDU0PlFdbwsCfDqfeZtM1I7HoiCQqQU/edit?_ga=2.51795946.295897976.1650813767-1484916684.1650813767# which "_P2_BOOT.BIX" is stated to be the proper format.
I did also notice that in Cluso's post he used _BOOT_P2.BIX so I have been using both during testing just in case, both with the same results. I am currently using the guide from the TAQOZ glossary to format a couple different SD cards and hope one stick ha.
I have had problems if I renamed the file on the card. I don't know why. Save it locally as _BOOT_P2.BIX and copy to the card.
Make sure the card is formatted FAT32.
*I updated the post. Accidently prepended the filename with an underscore.
** I was right the first time. Needs the underscore.
Confirming it should indeed be _BOOT_P2.BIX
The doc update was submitted. Thanks for the alert on the error, and apologies to @mccarthr for the confusion and time lost.
even if you a file rename or copy windows does magical things with filenames for 8.3 FAT32. It really likes to even save a 8.3 filename as Longname file.
You really need be sure that the sd directory contains a file named BOOT_P2.BIX not _BOOT~2.BIX or such nonsense.
copy from console and giving both path/file?
dunno
Mike
I image it’s something to do with the board being custom.
What crystal freq do you have?
I’d double check the pull-up / pull down arrangement.
Odd. I thought I had posted this already.
Like others here, I have had problems with SD cards on the P2. The P2 Evaluation boards I have are all finicky. Also, there are differences between the RevA boards and the RevB boards. I do not have a RevC board, so I don't know if this version boots more reliably.
As others have reported, successfully booting the P2 from an SD Card seems to depend on both the brand and the size of card. SanDisk cards seem to work most reliably, Verbatim cards often won't boot at all, or will boot once but then require physical removal and re-insertion before they will boot again. I have some cards that will boot reliably from either a hardware or a software reset, some cards that will boot from a hardware reset but not from a software reset, and some cards that will not boot at all, but which seem to work perfectly well in other devices.
If anyone has any code that can reliably reboot the P2 so that it then loads from the SD card, and which works for a variety of SD card brands and sizes, please post it.
Ross.
(the following is my testing/understanding, its not official or definitive...)
The physical removal & re-insertion issue -
Many (not all) SD cards seem to need an extra clock or two in order to release their SO line. I went through a dozen brands/types and wrote on each whether they needed 0, 1 or 2 extra clocks in order to release their SO, which enables them to also 'second boot' (from a reset) successfully.
I found one card that just didn't want to release even with many clocks.
Software solution - early in your program, add 2 or more extra SD clock cycles. This should enable a successful reboot from that point on
Hardware solution - drop the power to the SD card during reset. I think Peter did this on his later P2D2 design
The card that worked best for me was a red and grey Sandisk Ultra 16GB, common at officeworks. Coincidentally this is the one I think Cluso did most testing with. It didn't need any extra clock cycles in order to boot multiple times. However, I think I found much larger sizes in that same range did need an extra clock (though my memory is hazy on this)
I have a SanDisk 8Gb card that works very reliably. The amount of time I have wasted investigating problems with other cards - assuming it to be a problem with my software - is simply beyond belief
Now whenever I have a problem I suspect may be SD card related, the first thing I do is re-test using this card. What I will do if this card ever fails I don't know
I can look at adding a few clock cycles to my code, but there is not much I can do about the P2 boot code
Ross.
FYI - The P2-EVAL RevC also has a similar option available (SD card and SPI Flash are reset when the reset button pressed).
In addition there's a footprint to connect P2-IO57 as a power on/off signal to allow power-cycle of the SD card and Flash chip from user code, or allow lower current sleep modes/etc... (Really that was for testing & power analysis, but might be useful in some apps).
I can imagine dropping power to uSD card on reset helping a lot with SD card being stuck in some mode issue.
@mccarthr Maybe try booting from uSD by cycling power to your board instead of pushing a reset button or doing a soft reset.
Or, physically removing the uSD and then reinstalling before hitting reset.
Personally, I think it'd be more robust to boot first from flash and then load code from uSD (using different pins) if needed.
P2-EVAL RevB also has almost exactly the same circuit configuration, except for R802 value being 27 Ohm on RevB, where, on RevC, it is shown as being 1K Ohm.
Does that difference represents any evolution on the way U801 interprets/senses its EN-pin, due to any Common_VIO_Enable (time/ramp-up/ramp-down-wise) level changes?
More likely 1k is a better choice, for if someone has R803 fitted (or it may be simplify BOM) .
1k avoids an excess conflict between reset button and P2 port IO.
Didn’t know about R803…
Maybe I’d try just solder bridging it.
Can that work?
Thanks @jmg
Despite it can appear to not being relevant to the current discussion, does anyone can tell me from where comes the biasing that internally powers P2_RESN input pin?
I just noticed how widely P2_RESN-signal connects to several control points at P2_EVAL (at least on Revs B, and C), spreading far away from the P2-chip itself, and pending further detail on any "to-the-outside-world" leakage comming from that pin (suposedly to be ~1uA), at least two 3.3V-related power supplies met at the circuits involved in that discussion: COMMON_VIO, and VIO_56_63.
Thanks everyone for the very informative thoughts and ideas, I have been on vacation but will be giving all these a try tomorrow. I’ll report back with what worked and what didn’t but I’m hoping for some good news!
R100 is a 10k pull-up to V5663 on the Eval/Edge boards. Doesn't look like there is anything internal to the Prop2. Different to the Prop1.
Here's what the datasheet says: "RESN (reset) pin must always have a pullup resistor to 3.3 V (typically 10 KΩ)."
Thanks again, @evanh. It seems I've missed them totally; (R100) and the datasheet entry about RESN.