Compiler/CC2642R: On chip OAD

Sy10

Part Number: CC2642R

Tool/software: TI C/C++ Compiler

Hi,

I started using the new cc2642R1 chip, and I was hoping the "on chip" OAD option will allow two images to be stored on flash, having a backup image in case something goes wrong during OAD.

The size of my application (user+stack) is 187K (which is 53% of the available flash, excluding the 8k flash for last page) - this means two images will not fit.

The concern I have with the "on chip" OAD concept described here: http://software-dl.ti.com/simplelink/esd/simplelink_cc13x2_26x2_sdk/3.30.00.03/exports/docs/ble5stack/ble_user_guide/html/oad-secure/flash-layout-on-chip-stack-library.html#constraints-and-requirements-for-on-chip-oad-stack-library is that the persistent app must be small and thus implying limited functionality and in case something goes wrong during the OAD, the device will be in limited mode.

In my case, this device is driving a co-processor and the fact that there is chance that the main application could get corrupted during OAD is simply not acceptable.

To solve this, I obviously have the option to try to reduce my application (app+stack) size (by removing certain features unfortunately) such that I can fit two instances on the flash, then modify BIM accordingly, while the applications themselves handle the actual OAD (receive the actual FW bytes). In my case, the new FW image is going to come through a serial connection, and the functionality to receive and handle the image is embedded into my main app - to receive new FW bytes, store them at the proper location on internal flash and let BIM take over and see if new image is valid - similar concept as the sample BIM, if new image is not valid, then we have the old image.

My question is:

Is it possible (does TI have an example) such that stack is linked separately so it is not included in both instances of the app. If this can be done, then I should be able to fit 1 x stack + 2 user apps on the 360K flash. This is exactly as the old cc2460 chips were handling this, and now it seems to me this concept will give me the redundancy of the OAD implementation I am looking for.

Is there anything else/another option TI can suggest to utilize to be able to make the OAD process failure prof - so we don't overwrite the main image of the user app and have no fallback in case something goes wrong?

Obviously, adding a flash chip will solve this, but I was hoping something else can be done - Thanks for your help and suggestions!

Ivan S.

over 6 years ago

0 Eirik V over 6 years ago

TI__Guru 56590 points

I have assigned an expert to comment.

0 Ivan Slavov over 6 years ago in reply to Eirik V

Prodigy 235 points

Thank Eric,

I am subscribing to this thread using my company's account

Thanks,

Ivan S.

0 Elin W over 6 years ago

TI__Genius 14845 points

Hi Ivan,

You don't necessarily have to remove features from your application. Depending on your use-case, it might be possible to shrink the application code size so you can fit two images in addition to BIM and the persistent app by optimizing the code. Can you share some more details on your use-case, for example why only two FW images are needed?

To my knowledge, there isn't a way to separate the stack into its own image to replicate the implementation for CC2640R2.

You shouldn't have to add something to not overwrite the running image. When the device is receiving a new image, the image running isn't overwritten and the BIM doesn't launch the new image until the CRC value has been validated and, if security is used, the image has been authenticated. That is one of the perks with OAD, even if the power is cut mid transfer, the BIM will still launch a valid image i.e. the previous image.

Thanks,
Elin

0 Ivan Slavov over 6 years ago in reply to Elin W

Prodigy 235 points

Elin,

thanks for your response!

here are some more details about our case:

the main app is 199K looking at the memory map in CCS (this includes 16K (0x32000-36000) added for NVS), without this NVS area the top address the app goes up to is:

0x2C840

this means our main app goes up to memory page 23 (0x2C000-0x2E000), from my understanding we have two more pages for app to grow (0x2E000-0x30000 and 0x30000-0x32000)

Here is an update about our progress, we are very close to proving the concept, I have some errors trying to save new FW bytes to flash. please see below:

=================================================================

I was able to start with the sample persistent app, remove OAD GATT service (the entire oad task from the sample), and add a small UART task, and I can run the 3 apps - BIM, Main User App, and the Persistent App.

When the main app receives a signal for FW update, it fetches the firmware on wifi co-processor, then runs persistent app which is receiving the FW image over UART.

My next challenge is, when saving the new FW starting to internal flash from address 0x0 and going up 23 pages.

1. if i simulate flash write, persistent app fine, I can see ALL FW bytes on the UART wire
res = FLASH_SUCCESS;

2. If i ONLY write flash (without erase), persistent app fine, I can see ALL FW bytes on the UART wire

res = writeFlashPg(flashbuffer_page,flashbuffer_pageoffset,pBuf,len);

in this case, if i read the flash off the tag, I see new bytes being written (from the new image, for example image header CRC coming from the OAD bin i pushed, and I know the user app when flashed first does not have CRC, it has default 0xFFFFFF). I know, firmware is coming in, and seems like erase is needed in order to write properly - correct?

3. If I erase page and then write flash, persistent app hangs writing the last page, I can still see ALL FW bytes on the UART wire

if (flashbuffer_pageoffset == 0)
eraseFlashPg(flashbuffer_page);

res = writeFlashPg(flashbuffer_page,flashbuffer_pageoffset,pBuf,len);

Some more details,

In the NVS settings I had to increase the NVS flash area for the app region size from 0x2a000 to 0x32000. without this the write to memory over 0x2a000 would return an error, and our app is going higher. here are my nvs settings:

#if defined(__TI_COMPILER_VERSION__)

#pragma LOCATION(flashBuf0, 0x32000);
#pragma NOINIT(flashBuf0);
static char flashBuf0[0x4000];

#elif defined(__IAR_SYSTEMS_ICC__)

__no_init static char flashBuf0[0x4000] @ 0x32000;

#elif defined(__GNUC__)

__attribute__ ((section (".nvs")))
static char flashBuf0[0x4000];

#endif

NVSCC26XX_Object nvsCC26XXObjects[2];

static const NVSCC26XX_HWAttrs nvsCC26XXHWAttrs[2] = {
    /* CONFIG_NVSINTERNAL */
    {
        .regionBase = (void *) flashBuf0,
        .regionSize = 0x4000
    },
    /* CONFIG_NVSINTERNAL1 */
    {
        .regionBase = (void *) 0x0,
        //.regionSize = 0x2a000
        .regionSize = 0x32000//0x2a000 //0x32000 AiRISTA extend to use all available pages
    },
};

is there any usage restrictions to these higher flash pages

25		0x30000
24		0x2E000
23		0x2C000

do you have an idea or suggestion of what I can try to ensure the new FW bytes are written to flash?

0 Ivan Slavov over 6 years ago in reply to Ivan Slavov

Prodigy 235 points

Hi,

To give ALL update,

I was able to prove the concept and do an OAD using a custom persistent app, getting FW through serial UART (from a wifi co-processor). All memory mappings above were correct. Issue with the writing the last page was timing with co processor

Next, I would try using a bare-bone persistent app without BLE stack and update memory maps to give more memory to main app and shrink the persistent app ranges (as it wont have the BLE stack)

Thanks,

Ivan Slavov

0 Elin W over 6 years ago in reply to Ivan Slavov

TI__Genius 14845 points

Hi Ivan,

Thanks for letting us know that you found a solution to your problem and what it was.

Thanks,
Elin

Bluetooth®︎

Bluetooth forum

Compiler/CC2642R: On chip OAD