Thats a neat video explanation of the problem, Terry
You might be able to fix the problem by adding some extra SD card clock pulses somewhere in your code, so its ready for the next reboot.
Some time ago I tested a wide range of 64 GB SDXC cards. The results are on here somewhere. Most of the cards just needed more clock pulses. Some needed a pulldown on P58. There were some cards that 'just work' and don't need anything extra, but you'd have to ship those specific cards with your product. There was one card that wouldn't work more than once, regardless of clock pulses or P58 resistor.
The Team 64 GB sdxc I tested the other day for MicroPython is one of the lucky ones that just works. There was a sandisk red and grey 8GB in the past that also just worked, but the bigger ones in same series need assistance unfortunately
@pedward I've made some further progress today and I think some of the previous may be misleading, because perhaps the SDXC boot was failing and falling back to flash.
What I've confirmed today is
1. that PropTool 2.7 loads up the Flash with working MicroPython successfully, without reporting errors. So I expect anything from 2.7 to 2.9.3 should be OK
2. FlexProp 4.0.6 (that we used for testing) still loads up the Flash with working MicroPython successfully.
3. I've seen that repeating pattern you reported, on both P2EVAL and also the P2EDGE32MB today, when booting from a reformatted TEam 64GB SDXC.
4. I've bought a cheap samsung 64GB SDXC to test with something more purchasable, but so far I just get that repeating pattern mentioned
So now I'm less confident on the SDXC front than the serial loading front.
What I'm trying to do now is get a later version of FLexProp working. In 4.06 there wasn't a customisable flash string, but from comments it loads the P2ES_flashloader@0 and then P2NMP113 binary@1000. Should have some more to report soon
@pedward looks like the reason FlexProp isn't loading with later version is because the P2ES_flashloader.bin has grown from 5kB to 33kB
I've attached P2ES_flashloader406.bin which is from flexprop 4.06, and is only 5kB in size. Put it in your flexprop/board directory along with the other loaders
Back in FlexProp 6.1.5..
Under Commands/Configure commands, I use the following
Under Commands/Choose P2 flash program, select that P2ES_flashloader406.bin
Under Ports/Baud, select 115200 so you can see MicroPython come up inside the window, and type a command {such as help() } to verify that its working
then follow the usual instructions (COntrol-R to insert Step1, Control-E to insert Step2) and you should be all good
One thing I've seen is sometimes FlexProp seems to slip back to the later (33kB) bootloader. I think this is when you go into configure commands and click ók' Its why we set the commands/configure commands before choosing the p2 flash program, in the above steps
Let me know how this goes. Next, I'll see what I can do on the SDXC front, but I don't have a whole lot more time to spend on it
That succeeded and I immediately got a REPL, hit reset, got a REPL and it responds to input.
This works because the last ~13216 bytes of the uP binary are just 0x3F repeated. This is probably just garbage area, so truncating it by 4KB doesn't seem to matter.
That succeeded and I immediately got a REPL, hit reset, got a REPL and it responds to input.
This works because the last ~13216 bytes of the uP binary are just 0x3F repeated. This is probably just garbage area, so truncating it by 4KB doesn't seem to matter.
Why would the image be truncated?
512488 bytes loaded to $1000 in hubram should only extend to $7E1E8.
Some of this goes back a long way (before flashing tools were integrated). There's a good chance we can ditch Step1 now.
The SDXC approach still needs something simpler, which I think the Pi Imager can provide
Try just making a canned iso that you can burn to an SD. I'm not sure it matters if it's a proper iso, I think it just treats it as a blob that it writes to disk.
That succeeded and I immediately got a REPL, hit reset, got a REPL and it responds to input.
This works because the last ~13216 bytes of the uP binary are just 0x3F repeated. This is probably just garbage area, so truncating it by 4KB doesn't seem to matter.
Why would the image be truncated?
512488 bytes loaded to $1000 in hubram should only extend to $7E1E8.
Comments
Thats a neat video explanation of the problem, Terry
You might be able to fix the problem by adding some extra SD card clock pulses somewhere in your code, so its ready for the next reboot.
Some time ago I tested a wide range of 64 GB SDXC cards. The results are on here somewhere. Most of the cards just needed more clock pulses. Some needed a pulldown on P58. There were some cards that 'just work' and don't need anything extra, but you'd have to ship those specific cards with your product. There was one card that wouldn't work more than once, regardless of clock pulses or P58 resistor.
The Team 64 GB sdxc I tested the other day for MicroPython is one of the lucky ones that just works. There was a sandisk red and grey 8GB in the past that also just worked, but the bigger ones in same series need assistance unfortunately
@pedward I've made some further progress today and I think some of the previous may be misleading, because perhaps the SDXC boot was failing and falling back to flash.
What I've confirmed today is
1. that PropTool 2.7 loads up the Flash with working MicroPython successfully, without reporting errors. So I expect anything from 2.7 to 2.9.3 should be OK
2. FlexProp 4.0.6 (that we used for testing) still loads up the Flash with working MicroPython successfully.
3. I've seen that repeating pattern you reported, on both P2EVAL and also the P2EDGE32MB today, when booting from a reformatted TEam 64GB SDXC.
4. I've bought a cheap samsung 64GB SDXC to test with something more purchasable, but so far I just get that repeating pattern mentioned
So now I'm less confident on the SDXC front than the serial loading front.
What I'm trying to do now is get a later version of FLexProp working. In 4.06 there wasn't a customisable flash string, but from comments it loads the P2ES_flashloader@0 and then P2NMP113 binary@1000. Should have some more to report soon
@pedward looks like the reason FlexProp isn't loading with later version is because the P2ES_flashloader.bin has grown from 5kB to 33kB
I've attached P2ES_flashloader406.bin which is from flexprop 4.06, and is only 5kB in size. Put it in your flexprop/board directory along with the other loaders
Back in FlexProp 6.1.5..
"%D/bin/loadp2" -k %P -b%r "@0=%F,@1000+%B" -t -k -v
Under Commands/Choose P2 flash program, select that P2ES_flashloader406.bin
One thing I've seen is sometimes FlexProp seems to slip back to the later (33kB) bootloader. I think this is when you go into configure commands and click ók' Its why we set the commands/configure commands before choosing the p2 flash program, in the above steps
Let me know how this goes. Next, I'll see what I can do on the SDXC front, but I don't have a whole lot more time to spend on it
I tried this loader with flexprop and couldn't get it to flash properly, so I ran this command in the shell:
bin/loadp2 -p /dev/ttyUSB0 -b 115200 -t -CHIP "@0=board/P2ES_flashloader406.bin,@1000+p2nmp_bin/P2uP_1_0_124.binary" -k -vThat succeeded and I immediately got a REPL, hit reset, got a REPL and it responds to input.
This works because the last ~13216 bytes of the uP binary are just 0x3F repeated. This is probably just garbage area, so truncating it by 4KB doesn't seem to matter.
Why would the image be truncated?
512488 bytes loaded to $1000 in hubram should only extend to $7E1E8.
Ok, its good you got there at last
Some of this goes back a long way (before flashing tools were integrated). There's a good chance we can ditch Step1 now.
The SDXC approach still needs something simpler, which I think the Pi Imager can provide
Try just making a canned iso that you can burn to an SD. I'm not sure it matters if it's a proper iso, I think it just treats it as a blob that it writes to disk.
I keep seeing 512488 as 524288 in my head.