CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Has anyone successfully used Dual Partition Flash Program

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
drolleman



Joined: 03 Feb 2011
Posts: 116

View user's profile Send private message

Has anyone successfully used Dual Partition Flash Program
PostPosted: Sun Sep 09, 2018 1:17 am     Reply with quote

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



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sun Sep 09, 2018 9:04 am     Reply with quote

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

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



Joined: 03 Feb 2011
Posts: 116

View user's profile Send private message

PostPosted: Sun Sep 09, 2018 1:24 pm     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Mon Sep 10, 2018 12:44 am     Reply with quote

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



Joined: 23 Oct 2006
Posts: 33
Location: South Africa

View user's profile Send private message Visit poster's website

Dual Partition Flash
PostPosted: Wed Oct 03, 2018 11:11 am     Reply with quote

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



Joined: 01 Dec 2016
Posts: 17
Location: IL, USA

View user's profile Send private message

PostPosted: Sun Feb 03, 2019 5:59 pm     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group