• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 82 subscribers
  • Views 325 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.

TMS320F280039C: Flash memory allocation for doing firmware update

Johnny Chen
Expert 4910 points
Part Number: TMS320F280039C
Other Parts Discussed in Thread: UNIFLASH

Tool/software:

Hi Champ,

I am asking for my customer. They are evaluating memory allocation for doing firmware update for near future design.

1. For doing offline fw update, if the new image going to update is larger than a flash bank, user could separate the new image into two parts, erase / program to a complete flash bank, and the rest of the image be erased / programmed to other few flash sectors in another flash bank. It is feasible to do in such way, right ? 

2. For doing LFU w/ or w/o reset, in the LFU example, the old and new image are assumed to fit into a flash bank, then keep the dual banks (i.e. bank 0 and bank 1) symmetrical in design. What if in the same scenario, when the old and new image are both larger than a flash bank, how to design with the memory allocation when doing LFU ?

Is it the same way to sperate the third flash bank (bank 2) into two, 8 sectors for each old and new image allocation, then design it with symmetrical memory allocation ?

Thanks for the input.

Regards,

Johnny

  

  • 0
    TI__Mastermind 25930 points

    Johnny,

    1. For the offline update case, there are no constraints.

    "user could separate the new image into two parts" -> this is not necessary. The user's application will have a linker command file where you will specify where the code (.text) is going to. If the code is large enough that it needs more than one Flash bank to fit into, the .text will need to be mapped to a large enough Flash region. After that, nothing more needs to be done. The offline Flash programming utility that you use (whether CCS or UniFlash or Flash kernels or some other method) can ensure that Flash is programmed by running the Flash API library from RAM.

    2. In this case, it would be a bit more tricky. There are 2 potential issues with the approach you suggest (Bank0 = flash kernel + portion of old app, Bank1 = flash kernel + portion of new app, Bank2 = remaining portion of old app + remaining portion of new app

    a. Linker trampolines. You will allocate code in the linker file like this (e.g. for the old app). 

    .text            : >>FLASH_BANK0 | FLASH_BANK2_TOP_HALF,   ALIGN(8)

    There is a possibility that the linker throws an error like below. This would occur because the Flash sections are disjointed. One way of getting around this error would be to explicitly allocate functions in code to either Bank0 or Bank2. But it would be tedious.

    "program will not fit into available memory, or the section contains a call site that requires a trampoline that can't be generated for this section. placement with alignment/blocking fails for section ".text"

    b. This is the more serious issue that could occur. In the 2 bank case, the Flash kernel in Bank0 would program the app in Bank1, and vice versa. So there is no RWW (Read while Write) of Flash. In the 3 bank case, during LFU, Flash kernel in Bank0 would program the app in Bank1 and Bank2. However, some of the old App is in Bank2 and might be executing during LFU. So we could potentially have a RWW situation of Flash. That can lead to unpredictable behavior and is not recommended. So then you would have to tell the customer to not run that portion of code during LFU, or run it from RAM etc. So it starts to add on conditions/constraints/things to look out for.

    Thanks,

    Sira