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.
Mario
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)
hw_ccfg_simple_struct.h
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,
Lucian
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.
3.5.6.3.Data type definitions
Name:
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;
extern uint32_t FREESCALE_PROD_DATA_BASE_ADDR[];
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,
Lucian