• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 975 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/CC1310: ROM function pointers remapping

Davide Flamini
Prodigy 20 points
Part Number: CC1310

Tool/software: TI-RTOS

Hi,

I'm trying to write my own RF bootloader for CC1310.

The idea is to put the bootloader in the lower part of flash (0x0000 to 0x7FFF) and the application starting from 0x8000.

Everything works fine if I use BIOS in Flash but, when using ROM bios, I see that a lot of objects are placed in flash at absolute addresses starting from 0x1000.

Is there a way to relocate these objects (for example from 0x9000) to place them in the same flash area reserved for application?

I'd like to use ROM both in Bootloader and application so a fixed address is not possible.

  • 0
    TI__Genius 14860 points

    Hi,

    it's unfortunately not possible to relocate those objects. The ROM code requires those at fixed addresses. What you could do:

    • Distribute the bootloader to the first and the last flash page before the CCFG. You usually don't want to update the CCFG anyway because it would create security hole.
    • You could even think about placing the entire bootloader at the end of the flash right before the CCFG. On every update, let the bootloader replace the reset vector and stack pointer of the app binary before writing it to flash.

    The latter option is IMO the best solution because then you don't even need to care about linking the application to the correct address. Of course you would need a place holder to store the application's original SP and reset vector so that your bootloader could then jump to the correct address, but you reserve that at a fixed address in the app binary. 

    For the bootloader, you might consider using our No-RTOS driver porting layer. Depending on how many drivers you need, you can strip it down pretty much. If you use GCC, you could even recompile all libs with -flto. That will result in a smaller binary than a TI-RTOS application.

  • 0 in reply to Richard W.
    Prodigy 20 points

    Thanks Richard,

    Your first proposal is what I'm working on at the moment. The bootloader is located in the first 4k page and at the and of flash before CCFG.

    For bootloader I'm now using the TI-RTOS just because I didn't find a great size reduction when using no-rtos version but, of course, I don't need RTOS in the bootloader so I'll follow your suggestion to use gcc and recompile...

    Thanks again,

    Davide.

  • 0 in reply to Davide Flamini
    TI__Genius 14860 points

    I tried that a while back. Attached is a self-containing CCS project that integrates all necessary files into the rfPacketTx example. It's not clean, but you can beautify it on your own. You might also be able to strip some of the files. There will be some RAM footprint improvements in the next SDK release.

    I had to patch cpu.c because some asm statements were not protected by volatile and the compiler optimized them away. I don't remember if I had to patch any other file. Those issues will befixed in the next SDK release.

    rfPacketTx_nortos_flto.zip