AnsweredAssumed Answered

RT1050 OTA (GCC)

Question asked by Nikolaos Chatzinikolaou on Jul 4, 2018
Latest reply on Jul 10, 2018 by Fan Yang

Hi all,

 

We are trying to implement an over-the-air (OTA) image update mechanism for our RT1050-based product. We are not using a read-while-write flash and XIP, instead we copy-down the code to RAM and execute it there. Also, we are using gcc and CMake as our build system.

 

We have successfully managed to programmatically burn the contents of an imx.bin image generated by elf2sb (plus the FCB appended at the start), replacing the active image on flash, and the update works correctly.

 

However, next we would like to implement redundancy in the form of A+B image OTA.

 

We have have tried adding AT directives to the gcc linker file in order to place the .text (and .interrupts) sections on different locations in the flash image. These get picked up by ld, as shown in the paddr & LMA addresses of objdump's output of the .elf:


Program Header:
    LOAD off    0x00000000 vaddr 0x80000000 paddr 0x60020000 align 2**16
         filesz 0x00002400 memsz 0x00002400 flags r--
    LOAD off    0x00010000 vaddr 0x80010000 paddr 0x60030000 align 2**16
         filesz 0x00002178 memsz 0x00002178 flags rwx
    LOAD off    0x00020000 vaddr 0x80090000 paddr 0x80012178 align 2**16
         filesz 0x00000068 memsz 0x000020c0 flags rw-


Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .interrupts   00000400  80002000  60022000  00002000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .text         00002168  80010000  60030000  00010000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE


We have also tried generating a .srec, and have confirmed that the record addresses are correct (i.e. set to 0x6003xxxx).

 

However, elf2sb (and mfgtools when flashing) seem to ignore the LMA, and uses the VMA to position the code. So, in the example above, .interrupts would be flashed at 0x60002000 instead of 0x60022000, and .text at 0x60010000 instead of 0x60030000 (i.e. same as we hadn't used the AT directives in the linker file).

 

We have also observed that in the Boot Data Structure, the image's "start" field is expressed in terms of VMA addresses (just like the "entry" field in the IVT). i.e. They point to where the image is copied to, but not where it is read from.

 

Does that mean that the ROM's copy-down function requires the flash and RAM addresses to be aligned? Is there a way to tell the ROM to read the flash image from an address that does not correspond to the VMA that it copies to?

 

Thanks in advance,

 

Nikos

Outcomes