MKW30Z IAR 7.5 KSDK_1.3.0 How OTAP updating can preserves unit serial numbering

Showing results for 
Search instead for 
Did you mean: 

MKW30Z IAR 7.5 KSDK_1.3.0 How OTAP updating can preserves unit serial numbering

Contributor V
KW40Z_Connectivity_Software_1.0.1 (KSDK_1.3.0)
Programming a series of MKW30Z devices needs some sort of a serial number mechanism.

The Kinetis MKW30Z programmers implement this:
U-Cyclone -> AUTOMATIC SERIAL NUMBER MECHANISM -> 1 to 16 bytes in length
Segger ARM -> Serial number programming -> 1 to 4 bytes

Let's assume a 4 bytes SN works for both and the best way to store it is inside device_info BLE profile db.

The SN should be store to a specific address most likely i think.

When an OTAP update is done using external SPI flash either the:
- generic image data chunk (with that specific address) will be change in such a way to keep the specific device serial number
- or the boot loader will not erase the SN area at re-flash.

Witch one is the best approach ?

It is already implemented or how can this be done ?
Labels (2)
4 Replies

NXP TechSupport
NXP TechSupport

Hi Lucian,

The two options are good approach, but it will depend of your application.

1. In your code you declare a random SN, it will change if you want to update through the OTAP.

2. You could save memory for the SN number. In other words, you have to modify the linker file and the both firmwares should care to read  that specific section of the memory. You will keep that SN or other information that you want.

Hope it helps.

Let me know if you have more questions.

Best Regards.


Contributor V

Hello Mario,

The serial number is also stored in device info profile as an attribute (or at least a part of it).

I see some application where the serial number, hardware version and calibration constants are stored at end of flash.

(Customer Configuration Area in Lock Page)


cc13xxware/hw_ccfg_simple_struct.h at master · contiki-os/cc13xxware · GitHub 

Calibration constants like temperature, TSI, RTC, BLE MAC address,...

When OTAP runs is it can only update all flash except the end of flash - keeping that zone not modified ?

Can I lock the end of flash to keep it not modified ?

Or should I modify OTAP bootloader, or OTAP image file ?

Thank you,


0 Kudos

Contributor V
0 Kudos

Contributor V

Hello Mario,

In Document Number: CONNFWKRM
Connectivity Framework, Reference Manual, Rev. 1, 09/2015
3.5.6. Production Data Storage

For this purpose, the last FLASH sector is reserved, and contains hardware specific parameters for production data storage.

This sector is reserved from linker file, through the FREESCALE_PROD_DATA section and it should be read/written only thorough the API detailed below.

This sector is not erased/written at code download time and it is not updated via over-the-air firmware update procedures, in order to preserve the respective node-specific data, regardless of the firmware running on it. type definitions
typedef PACKED_STRUCT hardwareParameters_tag{
    uint8_t reserved[50];
    uint8_t ieee_802_15_4_address[8];
    uint8_t bluetooth_address[6];
    uint32_t xtalTrim;
    uint32_t gInternalStorageAddr;
} hardwareParameters_t;

Defines the structure of the HW dependent information.
Some members of this structure may be ignored on a specific board/silicon configuration.
Also, new members may be added for implementation specific purposes, but the backwards compatibility must be maintained.

The structure is found in Flash_Adapter.h but different:
typedef PACKED_STRUCT hardwareParameters_tag
    uint8_t  reserved[42];             /* for backward compatibillity */
    uint8_t  ieee_802_15_4_address[8]; /* IEEE 802.15.4 MAC address */
    uint8_t  bluetooth_address[6];     /* Bluetooth address */
    uint32_t xtalTrim;                 /* KW4x only */
    uint32_t edCalibrationOffset;      /* KW01 ED offset */
    uint32_t pllFStepOffset;           /* KW01 fine tune pll */
    uint32_t gInternalStorageAddr;     /* The start address of the internal storage used for OTA update.
                                          A value of 0xFFFFFFFF means that the External storage is used. */
} hardwareParameters_t;


What are these reserved[42] bits for backward compatibility ?
Why are they needed for ?

There is a limit for this structure on MKW30Z ?

Why bluetooth_address is not use to set the actual BD_ADDR  in ble_controller_task.c (
gBDAddress_c[6] = {BD_ADDR} ) ?

Best Regards,


0 Kudos