CC2640R2F: image flashed is not persisted on chip reset

Hi Django,

You could read the device memory before/after the reset using FLASH-PROGRAMMER or UNIFLASH and compare results.  Depending on the initialization of host_test, GAP Bond Manager nonvolatile memory storage could be achieved by the Simple NV Area.  See the Flash and Non-Volatile Storage Architecture sections of the BLE-Stack User's Guide for more information.

Also, what are the data address and size parameters of your bootloader COMMAND_CRC32?  This could vary from your other CRC computation.  Please refer to SWRA466 and Chapter 8 of the TRM for further bootloader details.

Regards,
Ryan

The base address and the size is same in both cases (address 0 ,size 131072),

I have dumped the CCFG register contents, in case any invalid values are set:

CCFG reg name : Extern LF clock configuration Value 0x1800000
CCFG reg name : Mode Configuration 1 Value 0xff820010
CCFG reg name : CCFG Size and Disable Flags Value 0x58fffd
CCFG reg name : Mode Configuration 0 Value 0xf3bfff3a
CCFG reg name : Voltage Load 0 Value 0xffffffff
CCFG reg name : Voltage Load 1 Value 0xffffffff
CCFG reg name : Real Time Clock Offset Value 0xffffffff
CCFG reg name : Frequency Offset Value 0xffffffff
CCFG reg name : IEEE MAC Address 0 Value 0xffffffff
CCFG reg name : IEEE MAC Address 1 Value 0xffffffff
CCFG reg name : IEEE BLE Address 0 Value 0xffffffff
CCFG reg name : IEEE BLE Address 1 Value 0xffffffff
CCFG reg name : Bootloader Configuration Value 0xc5ff15c5
CCFG reg name : Erase Configuration Value 0xffffffff
CCFG reg name : TI Options Value 0xffffff00
CCFG reg name : Test Access Points Enable 0 Value 0xffc500c5
CCFG reg name : Test Access Points Enable 1 Value 0xff000000
CCFG reg name : Image Valid Value 0x0
CCFG reg name : Protect Sectors 0-31 Value 0xffffffff
CCFG reg name : Protect Sectors 32-63 Value 0xffffffff
CCFG reg name : Protect Sectors 64-95 Value 0xffffffff

I do not see a correlation between CCFG registers and the behavior you are describing.  Have you made any pertinent changes to the host_test project?  I'm still waiting for the results of the memory dump to provide more information.  Can you share your exact bootloader CRC32 command and do you use sblAppEx to test the bootloader?

Regards,
Ryan

Have you made any pertinent changes to the host_test project?

I just changed the CCFG register contents to reflect the setting of  "CCFG reg name : Bootloader Configuration Value 0xc5ff15c5", Other than this no changes done to the host_test project.

I have attached two files named flashed-1xt ( which is the entire flash content after flashing the binary) and the other one is when the chip is restarted  after flashing named flashed-2.txt. Of course they do differ in some portions where the bytes are 00 are filled with FF. 

Yes I am using the sblAppEx to test the bootloader and I have not made any changes to the sending SblDeviceCC2650::CMD_CRC32 command.
The payload sent remains the same and the start address is set to 0x0 and the BytesCount is always set to 131072

Let me know if you need anymore information.

2275.flashed-1.txt

8053.flashed-2.txt

BR,

django

Ok now I understood the problem. I see that the checksum of the image can change after its been flashed.

Basically, the idea to compute checksum on every startup was to check for the image update (if the checksum of the image file  and the checksum on the flash differ, then the flashing is performed and if the checksums are same then the flashing is not performed).

Any other way we can achieve this functionality ? Something like writing version string into the image or to some flash area to read in bootloader mode ?

Best Regards,

Django