MSP430FR5969: Custom I2C bootloader with dual images and fallback capability

Hi Paul

This is our work flow of the dual image as below you can find it in the user's guide  

That is similar with your description "check the CRC of the current image. If the CRC fails, fall back to the alternate image. If the alternate image CRC fails, fall back to the bootloader, and wait for a new image" and the down load area is not shared with app area. You can just seem the down load area as app 2. 

Best regards

Gary

Thanks Gary,

I was looking at the wrong linker command file at first, and in the dual image one I see the separate download area from 0x10000 to 0x13FFF. 

It seems like using the MPU to help control access to the different regions would be good bulletproofing for my code. It looks like I can control Read/Write/eXecute access to three memory ranges and information memory distinctly.

Does this seem like a good approach?

Memory regions: 

INFOA : origin = 0x1980, length = 0x0080
INFOB : origin = 0x1900, length = 0x0080
INFOC : origin = 0x1880, length = 0x0080
INFOD : origin = 0x1800, length = 0x0080

_Boot_Start = 0x4400; /* Start of BootLoader area */
_Boot_End = 0x4FFF; /* 3k for Bootloader */
_Appl_Start = 0x5000; /* Start of Application Space */
_Appl_End = 0xEFFF; /* 40k of memory */
_Down_Start = 0x10000; /* Download Area */
_Down_End = 0x13FFF; /*16k of Download Area */

Initialization of memory controls:

void _system_pre_init(void)
{
//set info memory to be write protected, execute protected, read enabled
//create segment borders in : bootloader, App, download
//protect bootloader from write, allow execute and read 
//allow application write,execute, and read

//protect download from write, execute, read
//enable MPU
}

in JmpToBootLoader(), the first action would be to change RWX permissions on the bootloader and download regions

I'm starting to realize how many details there are here which I hadn't fully grasped before.

If I understand the MSP430FRBoot example, it is actually compiling the bootloader and the application as separate projects. It seems like this would be a bit risky in terms of making sure that the bootloader and application memory configuration are compatible. I guess this could also be done with build configurations... Please forgive my learning curve here!

Is there an application note or wiki entry that will help me understand the following? How would you generate a compiled output file that doesn't include all of the possible memory spaces? (It would be fine if my bootloader code overwrote application space, but I need my application output file to only be the size of the application space!)

Hi Gary,

I certainly appreciate your help... I am still enough of a beginner that some details are confusing me. Assuming I have a complete bootloader, how can I use CCS to generate the code file for the App, containing only the memory space I want to update? I have been looking at the Apps that come with the MSP430FRBoot example, and I don't see any indication of this. It seems like the linker command file has some variables that might be used for locating the app main() in memory, but I don't see them referenced anywhere in code... IT also seems as though the .out file would likely include the entire memory map, so how does the App-only portion of the memory map get extracted from this file for the update process?

Thanks,

Paul

Hi Gary, I am starting to piece things together, I believe. Please let me know if I have the sequence of events correct here:

1. The Target Application is built, and the msp430hex utility is used to convert the .out filt into a .txt file.
2. The .txt file is run through a perl script which parses it and exports only the application code into a special .c file.
3. That .c file is included in the Host Bootloader project. When this project is built, the application is saved as a byte array to be sent when requested.

So, for a more generic approach, which does not rely on an MSP430 Host providing the image, we would primarily modify step 3, but step 2 might be a bit different to produce whatever file format the Host is designed to accept. Is that correct?