Flash usage in CC2640/50

I've been doing some testing and reading of the linker scripts, and I believe I found part of the reason I'm seeing this:

• The last page of the Flash seems to be destinated to the CCFG section, but .text, .const, etc, are still allowed to go there, and for some reason the Memory Allocation tool is not displaying this.

    // CCFG Page, contains .ccfg code section and some application code.
    FLASH_LAST_PAGE (RX) :  origin = FLASH_SIZE - 0x1000, length = 0x1000

    .text           :   >> FLASH | FLASH_LAST_PAGE
    .const          :   >> FLASH | FLASH_LAST_PAGE

So I would expect the linker to work properly and put those sections there if the main FLASH area is full, but I'm not sure if my understanding is correct.

• On the BLE Stack linker file, I found these lines:

// Last page is reserved by Application for CCFG.
#define NUM_RESERVED_PAGES      1
#define RESERVED_SIZE           (NUM_RESERVED_PAGES * PAGE_SIZE)

    FLASH (RX) : origin = ICALL_STACK0_ADDR, length = FLASH_SIZE - RESERVED_SIZE - ICALL_STACK0_ADDR

Which seem to be reserving memory for that same section, at the end of the Flash.

If this is the case, and those unused bytes of the last page can still be filled with .text and .const, then that's fine by me. It would be great, however, if I could see those in the Memory Allocation view, or in some linker output file, so that I can monitor Flash usage.

I have not yet found the cause of the missing page between the Application and the BLE Stack.

Also, I found these lines on the Application linker file:

#define APP_BASE                0x00000000
FLASH (RX) : origin = APP_BASE, length = ICALL_STACK0_ADDR - APP_BASE - 1

which seem to be wrong, since the Application should start at 0x1000, not 0x0000 (where the bootloader is). I created the bootloader project starting from the OAD one (the BIM_extflash proejct), and it's working properly, so I'm not sure why those lines look like that. Is there a problem in my linker script?

Thanks!

Could someone give me a helping hand with this issue, or at least some guidance? I really need to solve this problem to continue development, and have not found any detailed information on this topic, either online or on the manuals.

Thanks

Hi Nicolas,

Both the first page (with resetVecs) and the last page (with CCFG) must be reserved for the bootloader. This is because if you lose power during erasure of either page, then the device will not start up, but either enter some lockup mode or the ROM bootloader.

The APP side should have FLASH from 0x1010 until ICALL_STACK0_START, meaning the length is ICALL_START - 0x1010. There is probably no mystery here. The APP, however, should not include the CCFG page (last page) if it's being used with a bootloader.

The STACK side should be from FLASH_START until FLASH_SIZE less one page for CCFG.

You don't specify this, but it seems you are using BLE SDK v2.1.1 or earlier. What I specify for STACK above is for 2.2. And the reason it starts at 0 is that the linker is for 2.2 told to squeeze everything in the stack image as far towards the end as possible (via FLASH(HIGH)), and after that figure out what the ICALL_STACK0_START should be for the application to cut off its length. This also means you don't have to re-compile the stack in 2.2 if it suddenly changes its size.

It seems to me that there is a problem with the map file for OAD used in BLESDK2.1, cc26xx_ble_app_oad.cmd

MEMORY
{
// ...
    #ifdef ICALL_STACK0_ADDR
        FLASH (RX) : origin = APP_BASE, length = ICALL_STACK0_ADDR - (APP_BASE + PAGE_SIZE) - 1 // <-- Should only subtract APP_BASE.
    #else // default
        FLASH (RX) : origin = APP_BASE, length = 0x0000CFFF
    #endif

Try not subtracting that extra PAGE_SIZE and you should see the memory allocation view show the correct and expected size.

Best regards,
Aslak

Hello Aslak! Thank you for your helpful response.

You're right, I forgot to mention this, but I'm using the 2.1.1 BLE Stack. I was also looking at the wrong linker script (ble_app.cmd instead of ble_app_oad.cmd), so that's where part of my confusion was coming from. I have now successfully removed the extra PAGE_SIZE and recovered 4kB for the App, which is great!

I have a couple extra questions regarding the Bootloader and the CCFG section. Looking at the Bootloader linker script, it looks like it's actually placed at the end of the Flash, not at the beginning as I suspected. Is it possible to put the Bootloader code on the first page, leaving the last page with just CCFG? And, if this is possible, is there a reason why I wouldn't be able to have the application also use that last page and fill CCFG itself, instead of relying on the bootloader to do so? This would greatly help with my code size problems.

Once again, thanks!

Edit: another quick question: the app linker script contains no directives for the .ccfg section, but it is being built and placed inside of the app region. Why is this happening? I thought the ccfg was built with the bootoloader and placed in the last page when using OAD?

Hi Nicolas,

No, the CCFG section must have at least some content, otherwise the device will not know that the Flash content is valid and won't boot. You are right that you could overwrite the blank areas left over by the bootloader. But you will 'never' be able to erase this data, because then you risk bricking the device, if power goes out during erase, but before writing in new data.

If the .ccfg section is not placed, then it will harmlessly end up somewhere in flash. You can exclude the ccfg.c file from the build to avoid this - it serves no purpose, and should not have been included in the build.

Best regards,
Aslak

Hello Aslak,

Hi Nicolas,

You should be able to do that, yes. But you risk bricking the device, because the boot that happens before any user code runs actually checks CCFG. If not present, it will enter the ROM serial bootloader. So you can not recover from that except with cables.

What you can do of course is identify some code that will never change and add this to the BIM project. You can then access this data via pointers, when you know the addresses. Or in your linker file add somthing like the below, pointing to known symbols in the BIM project, and access these as extern int myVariable or extern void *myFunction(int, char);
myVariable = 0x1f0004;
myFunction = 0x1f100 | 0x01; // Functions must have a 1 in the last addr bit to signify call in thumb mode

Alternatively, go ahead and re-write either sector0 or sector31 but somehow make sure you have enough battery/power available when you do this.

Best regards,
Aslak

Hey Aslak,

Thank you so much, you answers helped me better understand the problem, and I've now arrived at a solution that's more appropriate for my use case, using both the information provided here and on this other question: e2e.ti.com/.../449788

What I ended up doing is:
- I removed the KEEP_INTVECS symbol from the bootloader project, so it no longer uses page 0.
- I changed APP_BASE on the App linker script from 0x1000 to 0x0000, so now the app uses page 0.
- I changed M3Hwi.resetVectorAddress in appBLE.cfg to 0x0000 so that the device boots to the app's reset vectors
- I changed the jump address in the bootloader project to 0x0004, as well as the address where new binary images must be copied
- Since page 0 is now used by the app and not the bootloader, I reenabled the RTOS ROM implementation by adding these lines to appBLE.cfg:
var ROM = xdc.useModule('ti.sysbios.rom.ROM');
ROM.romName = ROM.CC2650;
- I also deleted the ccfg file from the app project to save a few extra bytes.

All in all, this increased the Flash space for my application by 10kB (4kB from the extra page, 6kB by using the RTOS directly from ROM).

The result is that the 'bootloader' is no longer a bootloader, but a different application that performs the firmware update and needs to be called explicitly from the main app. The device boots directly to the main app. The only drawback is that a power loss while the 'bootloader' is erasing/writing the Flash will cause the device to be bricked, but that's a risk I'm willing to take.

I believe this setup will work fine: if there's anything I'm missing that might cause issues, please let me know.

Thanks