BIN file generation for Flash
Larry Martin
Posts: 101
I'm implementing Flash firmware update over my embedded system's regular console port, copying @JonnyMac:
https://forums.parallax.com/discussion/175979/update-flash-from-sd
Three months after that conversation, What turned out to be the best way to make a BIN file that will "work" when loaded to P2 Flash , i.e., allow the P2 to boot from Flash?
Thanks to JonnyMac and @Wuerfel_21, I can:
- upload a PnutV42 BIN file, around 25KB, as hex records, in about 10 seconds to start address $6_0000 in P2 RAM
- reality check the image
- erase my flash using jm_p2_flash:brick_it()
- write the image to Flash
- reboot the P2
However, when I reboot, the firmware does not activate. The P2 sits there dead until I load something over PropPlug. Pnut -f (edit) and -r both get me going again.
Loading jm_flash_viewer in RAM with a PropPlug, I can inspect Flash and verify that everything I meant to write to Flash is in there. So I think I just need to generate the correct BIN format to support Flash bootup.
Just working with Pnut for the moment, it makes slightly different BIN files for different command line options. In -c compile mode it does not make a BIN at all. And sometimes it makes a BIN2. JonnyMac's p2img.py rejects every BIN I was able to make with Pnut42. This is typical output, from the BIN file made with the -r flag:
python3 p2img.py TCUv4P2_EncodeThreeReader.bin
Converting TCUv4P2_EncodeThreeReader.bin to TCUv4P2_EncodeThreeReader.p2img
- Input file size is 25204 bytes
- Output file size is 24852 bytes
- P2 image requires 7 flash sectors in P2
- P2 image occupies 98 flash pages
Loader Section Fixup
- $00001821 longs in application code
- $E8BDDAD5 is the sum of application longs
- $41A00480 is the loader sum
- $0FDC542C is the checksum
- Fail: checksum should be 0x706F7250 ... Aborting.
I gather that Pnut -f prepends a small flash loader to the BIN contents (0x0160 bytes long?), but I don't understand why the -r BIN file, which works when written to RAM, will not work when written to Flash. If the answer is to look at code because the docs don't cover this yet, a filename would be helpful.
Thank you.
Comments
During the last Parallax Zoom meeting @cgracey committed to having a compiler flag for PNut that would create an image of ones binary that would be loadable directly from an SD card (or other remote mechanism). The machinations I went through a couple months ago worked for me, but may have been with an earlier/different version of PNut. I'm hoping Chip sorts this out right away because I need to release a new product in March that includes the ability to update via uSD file.
Also, @macca made some changes to his P2 compiler to output a suitable image, though I haven't fully tested. You might check the Spin Tools IDE thread.
@"Larry Martin" I had a similar problem after reboot with my project. With my project, I boot from SD. I found that I had to send the SD card a CMD0 before rebooting. That places all of the SD card pins to float. I know that some SD cards have caused reboot issues because of this. I don't know if a similar thing must be done with the FLASH chip or not. But if you are using both the SD card and the FLASH, that can get complicated.
My project downloads firmware and supporting files from the Internet and self updates.
I am unsure why so many are skeptical of the using _BOOT_P2.BIX as a boot image on SD cards. It is completely reliable with quality cards, and built into the P2 firmware.
In my particular case I use the Flash for non-volatile storage. It seems with the standard Eval/Edge design one can use Flash or SD, but not both in the same code set. IMO, this was a terrible decision. The person that drove the decision -- who no longer participates in the Parallax community -- told me that it was to save one pin. One pin....
Where does loadp2:flash_loader_bin[] come from? (Is this a question for @Wuerfel_21 ?) Here's why I ask:
Today, I made a new BIN file using Pnutv42 -r. Then I loaded that file to Flash using my own compiled version of loadp2. My version sends a reset after programming is complete.
After power cycle, the board booted from Flash, verified by the Version banner. Dumping Flash with jm_flash_viewer showed this:
P2 Flash ViewerUnique ID...... E4618821 0B292835Manufacturer... EFDevice......... 17Manufacturer... EFMem Type....... 70Capacity....... 18 (16777216 bytes)[N]ext, [P]revious, [D]ata memory$00_0000 28 B6 65 FD 00 48 64 FC DC 40 9C F1 00 00 EC EC$00_0010 3C 94 0C FC 50 78 64 FD 3C 02 1C FC 58 78 64 FD$00_0020 1D 3C 60 FD 01 00 00 FF 70 01 8C FC 0A 46 CC F9$00_0030 20 46 20 F3 23 40 80 F1 05 46 64 F0 23 3E 20 F9$00_0040 01 46 64 F0 3C 46 24 FC 1F 06 64 FD 00 3E A4 FC$00_0050 24 36 60 FD F5 41 9C FB 3C 00 0C FC 00 00 7C FC$00_0060 21 04 D8 FC 12 46 60 FD 23 44 08 F1 50 76 65 5D$00_0070 00 04 64 5D 00 00 EC FC 00 00 00 40 00 00 F5 C0$00_0080 9D 18 00 00 9D 18 00 00 F0 EC B7 80 4A 88 78 7A$00_0090 10 AC 03 F6 11 AE 03 F6 20 0E A0 FD 28 1E 64 FD$00_00A0 00 00 6C FC 28 1E 60 FD 0D 00 68 FC 28 02 64 FDwhere the code 0x10AC at $00_0090 is the start of my BIN file. Flash contents match BIN file contents, to the end of each. Flash offset $00_7FF0 is erased to $FF. It looks like the only difference is that preamble. The preamble seems to come from flash_loader_bin in flash_loader.h of the loadp2 project, prepended to the input binary file in loadfilesingle(). The 0x28B6 at Flash offset 0 starts at offset 0x0160 in that array. The contents match from there to the values in paragraph $00_0080, which are all-zero in the H file.
So the next step for me is either reverse compiling flash_loader_bin[] or finding the source. Help?
Did you not see the
flash_loader.spin2sitting right next toflash_loader.h?Why no, no I did not. Thanks once again.