Retaining Previous configuration of the firmware during the OTAU upgrade process

[Swati Chikmath]

Hi Everyone,

I am working on OTAU upgrade for ATSAMR21G18A microcontroller in Zigbee network.


The microcontroller which is needed to be updated with new firmware using OTAU has the configuration details,
the configuration details like panid, channel mask , mapping detail (sensor, light mapping to controller).

When we upload new firmware to this node, the above configuration details should to retained.

The configuration details are stored in PDS, while uploading via OTAU this PDS section should be protected and should not be erased while firmware update.

How should I achieve this
Any help would be appreciated.

Thank you.

[ataradov]

I don't remember the details, but PDS data is stored at a fixed address. Just look in the PDS where it is stored. I think it was stored right after the vector table. Look at symbols __pds_ff_start, __pds_ff_end, __pds_fd_start, __pds_fd_end. This area needs to be preserved.

And if you are just starting a new system, I strongly recommend moving those sections after the application to some fixed address.

Another issue here is that you need to make sure that the size of the PDS does not change between the updates. Otherwise you need to read out the data, store it in some fixed format and restore it back after the update.

OTAU in ZigBee is a painful process, especially the way it is implemented in BC.

[Swati Chikmath]

Thank Alex

/* NVM layout */
FLASH   (rx)    : ORIGIN = 0x00000000, LENGTH = 252K   
EEPROM (rw!x) : ORIGIN = 0x0003F000, LENGTH = 4K

SECTIONS
{
   /* Code */
    .text :
   {
      __text = .;

      KEEP(*(.vectors)) /* Cortex-M0+ initial vectors table. Should be placed at the beginning of flash. */

      /* PDS NV memory section */
      . = ALIGN(0x100);
      PROVIDE(__d_nv_mem_start = .);
      . += ALIGN(0x4000); /* Size of D_Nv memory section is 0x4000 i.e., 16KB */
      PROVIDE(__d_nv_mem_end = .);
      
      /* Non-volatile file system PDS_FF section */
      PROVIDE(__pds_ff_start = .);
      KEEP(*(.pds_ff))
      PROVIDE(__pds_ff_end = .);

      /* Non-volatile file system PDS_FD section */
      PROVIDE(__pds_fd_start = .);
      KEEP(*(.pds_fd))
      PROVIDE(__pds_fd_end = .);

the above is ld file
------------------------------------------------------------------------------------
0x00004100                PROVIDE (__pds_ff_start, .)
0x000041b0                PROVIDE (__pds_ff_end, .)
0x000041b0                PROVIDE (__pds_fd_start, .)
0x000041d0                PROVIDE (__pds_fd_end, .)
this corresponds to .map file

Any changes in ALIGN will shift the complete code from a address specified in align. Some bigger number will lead to flash overflow(ATSAMR21G18A flash size = 256K bytes)

How shifting of PDS at the end of application could be achieved and how it can be protected from erasing while OTAU upgrade.

[ataradov]

You need to move those things after the .text and .rodarta section, not just adjust alignment. Linker specifies things in the same order as they would appear in the final binary.

You need to learn and understand how linker files work.

[Swati Chikmath]

Thanks for the information about PDS Alex.

Also i am confused with respect fake driver processing in OTAU.

since we don't have external flash memory currently tried the fake driver method to verify OTAU operation.
but i am not seeing any new image loaded to client after uploading via bootloader pc tool

will fakedriver bypass the switch option as mentioned in user guide or it will not store the image anywhere at all.

is there any other option for us to find how exactly client receives images via  OTAU server[debugging processes]

[ataradov]

I have no idea how the stock OTA works, you would have to look at the source code yourself.

I always implemented a different version.  Stock OTA implementation and tools are bad.