How can I repartition the Flash on a GIGA to the original factory state? I'd like to do some tests to make sure my sketch works well on a GIGA in the standard state as it comes from the factory with the default Flash partitioning.
My sketch automatically adds extra partitions and works great. But once the Flash has 4 partitions the QSPI Format sketch in the Examples folder no longer works. It yields the mbed red led lights of death. I can reformat again to 4 partitions OK using a version of your sketch and the board works fine again.
But how can I get it back to the original factory partitioned state so I can test things from there?
Hi Joe, I've been through the partition/re-partition/re-format loops a few times without issue. However, what I did do different was comment out the wifi lines so that I didn't have to run through the WiFi fw re-install. Might to worth trying that and see if it still crashes.
Steve I experimented with repartitioning again today.
Per our prior discussion I usually have 4 partitions and everything works great. I'd like to test the migration path from the factory standard partitions up to the 4 we use.
If I try the QSPIFormat Example sketch to repartition the Flash down from 4 to either 2 or 3 partitions I get the red LED of death as soon as I agree that partitioning deletes data. If I then run the QSPIFReadPartitions example the partition map looks like this. Clearly the partitioning is messed up, especially partitions 3 and 4.
Looking for Partitions on the Flash Memory... MBR Found
Boot Signature: 0x55AA
Printing Partitions Table and Info...
================================
Partition: 1
Bootable: No
Type: 0x0B
Size [KBytes]: 1020
Start [C/H/S]: 0/2/0
Stop [C/H/S]: 4/0/0
================================
Partition: 2
Bootable: No
Type: 0x0B
Size [KBytes]: 5120
Start [C/H/S]: 4/1/0
Stop [C/H/S]: 24/0/0
================================
Partition: 3
Bootable: No
Type: 0x0B
Size [KBytes]: 0
Start [C/H/S]: 56/1/0
Stop [C/H/S]: 56/0/0
================================
Partition: 4
Bootable: No
Type: 0x0B
Size [KBytes]: 2048
Start [C/H/S]: 48/1/0
Stop [C/H/S]: 56/0/0
No more partitions are present.
Total Space [KBytes]: 16384
Allocated Space [KBytes]: 8188
Unallocated Space [KBytes]: 8196
I can run a slightly tweaked version of your partitioning code to restore things OK.
It's now safe to reboot or disconnect your board.
Looking for Partitions on the Flash Memory... MBR Found
Boot Signature: 0x55AA
Printing Partitions Table and Info...
================================
Partition: 1
Bootable: No
Type: 0x0B
Size [KBytes]: 1020
Start [C/H/S]: 0/2/0
Stop [C/H/S]: 4/0/0
================================
Partition: 2
Bootable: No
Type: 0x0B
Size [KBytes]: 3072
Start [C/H/S]: 4/1/0
Stop [C/H/S]: 16/0/0
================================
Partition: 3
Bootable: No
Type: 0x0B
Size [KBytes]: 8192
Start [C/H/S]: 16/1/0
Stop [C/H/S]: 48/0/0
================================
Partition: 4
Bootable: No
Type: 0x0B
Size [KBytes]: 2048
Start [C/H/S]: 48/1/0
Stop [C/H/S]: 56/0/0
No more partitions are present.
Total Space [KBytes]: 16384
Allocated Space [KBytes]: 14332
Unallocated Space [KBytes]: 2052
So I can't quite figure out how to get back to a 2 or 3 partition state.
hmm, not sure why it didn't crash for me and I'm disappointed with my own testing as the MBR clearly retains old partition entries.
You can try this to clear from block 0 and overwrite the MBR but, as I don't currently have a board spare, it's untested.
Add this before the calls to partition:
Freed up a board to test this and, don't bother! What I've suggested above won't work. It runs ok and the partitionRead says no MBR but after the format you still get 4!!
It appears the chip is very protective of its first block. I can't see a way, with the APIs available, to wipe the MBR. It's probably why the 2 / 3 format sketch always does 3 regardless.
I'm going to dig into the datasheet for it tomorrow (time permitting) - thanks again for the learning experience
Hi Steve
I did try and it didn't seem to work for me either. I noticed that the example formatter sets unused partitions to zero size by setting the beginning and ending location to the same value. So even those zero size partitions still exist and calling TDBS.init on such a partition results in the red death LED instead of an error return, which I was using to trigger my partition upgrading code.
After a bit more searching I did find this: https://docs.arduino.cc/tutorials/opta/memory-partitioning/#partitioning-the-memory-of-a-portenta-machine-control
It does work to actually remove partitions, and it even adds the WiFi Firmware and certificates to the first partition but seems way overkill with lots of Erasing although that might in fact be be necessary. I commented out the line for the third partition and added in the example code to display the resultant partition map.
It leaves me with two partitions (WiFi and OTA) and no third nor fourth partition. So I think it comes close enough for my purposes to test my partitioning upgrade code. (Which seems to work fine.) I'm happy send you my unpartitioning sketch but it's pretty much straight from that Portenta link with the minimal changes I mentioned above.
Hi @steve9 and @JoeHuber, I am working ok reformatting the fs for mbed stm32h7 devices on mbed core. I am taking a look at what you did here, I really appreciate your work. If you want you can take a look on what I did here. If you have suggestions you are more than welcome!
What you are doing here is erasing a flash block and then writing 0s on the mbr table, did I get it right? It seems a bit redundant to me.
The tutorial here erases the entire flash, before writing a new partitioning scheme on the MBR.
From my understanding it is possible to clear the MBR table only, which is what I did here. Data on other partitions should still be preserved. I am double checking this, but if you can try it too it would be really helpful.
I've used that Opta sketch previously and it worked great to restore partitions. It seems to do a full erase so it takes a while to run and adds some wear to the flash. I liked that it installs the WiFi files and certs. I added code to also set up the 4 partitions we use and show a partition map of the results. This is much more convenient than running 3-4 separate Example sketches.
I wasn't able to see some of your info on GitHub due to some kind of permission or access issue.
As a minimum I do think it' worthwhile to make the partitioning Example more robust and not crash with the blinking RED LED when there are four partitions.
I reviewed the GitHub conversations, and I'd like to suggest that the three utilities be combined into one:
QSPIFormat
WiFiFirmwareUpdater
QSPIReadPartitions
If the user needs the partitioning one they likely need to run all three. I recognize there are also use cases where the WiFi and Partition Map ones are useful by themselves.
Maybe a simple menu system on a combined app is the best way to approach this. But it's definitely suboptimal to load three sketches, do three compiles, do three uploads and use three command line interfaces just to repartition the flash. That takes too much time and concentration. And if you want to tweak the partition sizes further you have to do all of that all over again.
I'm glad to see the formatter is being updated to be more robust. Thanks so much for your attention to that.
I have a project on a giga wifi with a need for some small data storage. I came across these three ino and would like to know how to determine the file system used. Or is it always FAT?
In QSPIFormat these lines specify the partition map and if/how to format them. They currently specify using a FAT file system for partitions 1 and 2. You can extend this to create a fourth partition if you want, and whether to use a FAT file system or a Little file system on each.