Has anyone successfully used Dual Partition Flash Program

[drolleman]

I'm looking at the feature on some 24/33 parts that have the"Dual Partition Flash Program Memory" using ccs.

Has anyone successfully implemented it?

[temtronic]

great.... now I can have TWO nonworking programs in one PIC !

I did actually download a 'how it works' PDF from Mchip..reminds me of the EEPROM BIOSes located in PCs, where you can update,verify THEN choose which to use.
I have enough 'fun' with the 46K22 so no need to update to 24/33 series.

Jay

[drolleman]

That is why I used the word successful. I'm looking to update on the fly, rather than shut down the system and restart the system which could take 20 minutes. This would save a lot of time.

David

[Ttelmah]

Big problem on the earlier chips, is that if you program the second space, switch to this, and there is a problem, the chip is 'bricked'....
The code that writes this needs to do a deep verification of what is loaded to absolutely ensure it is viable before initiating the switch. It is actually 'worse' than a basic bootloader in this. With the bootloader, provided you design it so it is protected, this is still running if the programming goes wrong, or the code itself is faulty. With the dual programming you are instead 100% commited....
The compiler has little to do with using this. It is always writing code to run in the memory model used. You just initiate the switch using the BSEQ registers.
Now some of the later chips have a protected boot option, which instead does allow your bootloader to be protected. Important to know which type of chip you are using?.

[johanpret]

I am also interested in hearing from people who used this feature in CCS. I would like to do OTA updates using this feature and some guidelines would be nice.
_________________
Johan Pretorius

[NAR]

I know this a little old thread but I've not been here for a while now and thought i mention how I did it.

I’ve not used the Dual Flash, not sure if this was available three years ago when I did mine, I just heard of this.

I have couple of products being used in the field since three years that have custom boot loader to do exactly that.

These unit use PIC18F66K40. Or basically any PIC that have more than double the size you need. The program is about 20K. So the bootloader splits the 66K40 to exactly half. And both halves are reserved using #ORG as usual.

Units also have a bluetooth BLE chip. and I built an iOS App for it.

OTA firmware upgrade is just by sending an encrypted HEX file to their email, or they click on a web site link (from the iOS device). The App is designed and registered to handle that custom extension and format so iOS launches the App and pass the file.

The App basically passes the HEX file line by line to the PIC via Bluetooth including full bi-directional support for re-transmission. The PIC Write_program_memory directly to the 2nd Half, and at the end if all conditions passes, it triggers a reserved memory location for that function and reset the cpu. When the boot loader loads, sees that location marked, it points all INT handlers and everything to the 2nd half. Now the entire program is running on the 2nd Half.

User have the option to go back to the first half (as it's still untouched) just by clicking that option in the iOS App, CPU resets and points everything to the first half. So they basically try the new firmware or even a fully new program and can revert back to the other one. If another firmware came, it gets stored in the (currently) unused half and so on.

Working like a charm and 100's of firmware update and trials been done that way. Updating 28K over bluetooth is less than 30 seconds. And is fully fail-safe as even if connection got lost or anything happen in-between during transmission, the current running application space is still untouched.

There is also a way to do the OTA without this complex bootloader which needs to point all INT handlers to different locations. I have used a simpler version in another device which did not need the option to go back. Running code always runs on the first half. The bootloader when it loads and see that location marked indicating a new firmware was updated on the 2nd Bank. It just copies that 2nd Bank to the first Bank, which is amazingly fast. This made the boot loader much simpler, standard, and just few lines. As the part that stores the new firmware into the 2nd half is done by the running application.

Obviously, there is a lot of check & balances in between and even for some critical use units, the marked location to swap the app is confirmed by a back-end server running on the internet if needed.

The simplest version would be as follow:
- Get a PIC that is twice as big.

- Reserve a balanced space for the bootloader so the rest of the PIC can be exactly cut in half. Which just makes copying much easier.

- Modify the standard bootloader so if it sees a specific set of numbers on one or more allocated bytes for this purpose, copies the 2nd half to the first half and clears the trigger byte(s) locations and reset_cpu.

- Put the code responsible to fill the 2nd half into the normally running application, the trigger to start the process could be various things, in my case it's not a switch or restart, it's just several hand-shakes and communication between the App and the PIC, and after the PIC gets the needed information from the App such as the size of the HEX, and decrypted signature and such, then it tells the App to start sending the code.

And yes, of course, both the bootloader and the loading routine within the running app must be fully debugged, tested and then frozen just to be sure.