| View previous topic :: View next topic |
| Author |
Message |
E_Blue
Joined: 13 Apr 2011
Posts: 419
|
| Does CCS Compiler support PIC24FJ with dual partition? |
 Posted: Thu Jul 23, 2026 8:43 pm |
 |
|
I want to develop a device with FOTA support and would like to know if there's any support by CCS Compiler to use the dual partition system in some PICs.
I have v5.091 of CCS Compiler.
The device I'm trying to use is a PIC24FJ1024GB606.
Any info about this will be appreciated.
_________________
Electric Blue |
|
 |
asmallri
Joined: 12 Aug 2004
Posts: 1671
Location: Perth, Australia
|
|
| Posted: Fri Jul 24, 2026 12:14 am |
|
|
| E_Blue wrote: | I want to develop a device with FOTA support and would like to know if there's any support by CCS Compiler to use the dual partition system in some PICs.
I have v5.091 of CCS Compiler.
The device I'm trying to use is a PIC24FJ1024GB606.
Any info about this will be appreciated. |
Not specifically what you ask for however...
I'm assuming you are asking this question as you would like to operate this PIC in dual partition modes (2 * 512k) partitions. In this configuration the partitions are essentially ships-in-the-night with neither being aware of the other with the exception that there is some basic setup required of the FBOOT, BTSWP bit and the FTBSEQ numbers.
One consideration for this mode is you basically have to have a copy of the bootloader in each partition. It also implies the bootloaders need their configuration in sync especially in an xOTA configuration with the 'A" meaning Air.
The easiest way to do this is to include the bootloader file in the application. This is the typical way you see it being done in examples of using the CCS supplied bootloaders.
I have been building and supplying bootloaders for PICs for private and commercial customers for years and the approach of embedding the bootloader within the application image is something I personally would not do with the exception of the production golden image.
In 20 years of deploying and supporting bootloaders in the field, I have only needed to upgrade a bootloader in the field update across a customer's network once and that was due to changing network protocols that occurred years after the original field deployment. Bootloader and specifically the flash memory they occupy should not be erased and reprogrammed just because you are updating the application.
The main issue with the dual boot mode flash configuration with the PIC24FJ1024GB606 MCU is the inability to get the device to boot to the other partition in the event of a failure in the active partition. For example, if the application code in the active partition has a problem that causes it to remain in a loop, there is no mechanism to enable the MCU to swap to the other partition. A WDT reset does not help as the MCU will reboot into the same problem partition. This MCU does not a multi-strike auto-rollback register flag and therefore the bootloader, before passing control to the application, is not able to detect that the application has repeatedly reset from a WDT trigger to the processor so the bootloader boots to the problem partition and you have an endless loop.
This means there is no real advantage of using a dual boot mode flash configuration with this MCU as it adds complexity with little benefit. Ultimately for reliability, both types of bootloaders need to maintain some form of external status information for them to remain in bootloader mode when the bootloader detects the continuous reboot problem.
If you are still in the early stages of design, you might want to consider a PIC24 that supports dual boot and supports the multi-strike auto-rollback register flag thus enabling the bootloader to detect the fault and have the bootloader initialise the active partition swap.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
E_Blue
Joined: 13 Apr 2011
Posts: 419
|
|
| Posted: Sat Jul 25, 2026 3:31 pm |
|
|
Thanks for the detailed information. You’ve given me several things to consider, especially regarding the lack of an automatic rollback mechanism and the implications of using the dual-partition configuration.
My current approach is to implement the FOTA functionality within the application itself, since the device already has to manage the modem and the communication required to download the firmware. I’m still evaluating the best architecture for the dual-partition mechanism, so your comments have been very useful in that regard.
I appreciate you taking the time to share your experience and insights. Thanks again!
_________________
Electric Blue |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 20112
|
|
| Posted: Mon Jul 27, 2026 1:01 am |
|
|
The one place where the dual partition can help, is allowing you to have
more sophisticated loader code, which is run while the system keeps
operating.
The default behaviour on boot is that it will boot whichever partition has
the newer ID. You can also program while the code is still executing in
the other partition (provided the protection is setup to allow cross partition
programming). So what you can do is have the executing partition program
the other, _and check that the code is valid_, before setting the ID. Then on
the next reboot, the new code will be executed.
It sounds as if this may be what you are thinking of doing. Remember though,
that the loader code should really always be separate from the main code,
otherwise a single fault in the new code, will then prevent you being able to
recover.... |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9650
Location: Greensville,Ontario
|
|
| Posted: Tue Jul 28, 2026 5:16 am |
|
|
curious ...
wonder if it's possible to have some code in 'main' than when it goes 'walkabout' or 'hung' or stops, the PIC would run the other program ??
some kind of failsafe to run the 'backup' program ? |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
