This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2652R: sblAppEx device CRC question

Part Number: CC2652R

I checked with sblAppEx_1_03_00_00 source file sblAppEx.cpp and found its flow steps for cc2652 chipset are listed below:

(1) collect some variables (baudRate, deviceType, fileName, devFlashBase, bEnableXosc),

(2) Create SblDevice and connect.

(3) Open FW file (fileName size is 360448 bytes) and calculate file checksum to have fileCrc value.

(4) Erase flash (360448 bytes) and write flash (360448 bytes).

(5) Calculate CRC checksum of flashed content to have devCrc value.

(6) Compare fileCrc and devCrc to make sure FW flash is OK or not.

(7) Reset device.

If I add extra step ( same as (5) ) between (3) and (4) for not to flash FW when the FW is same as flashed content as below:

(1) collect some variables (baudRate, deviceType, fileName, devFlashBase, bEnableXosc),

(2) Create SblDevice and connect.

(3) Open FW file (fileName size is 360448 bytes) and calculate file checksum to have fileCrc value.

(4) Calculate CRC checksum of flashed content to have devCrc value [Value A]. Compare fileCrc and devCrc & not to flash FW when the FW is same as flashed content.

(5) Erase flash (360448 bytes) and write flash (360448 bytes).

(6) Calculate CRC checksum of flashed content to have devCrc value [Value B].

(7) Compare fileCrc and devCrc to make sure FW flash is OK or not.

(8) Reset device.

My question is : will the [Value A] be same as [Value B]? And why?

(Note: we had ported sblAppEx to ARM platform but I verify & find [Value A] seems have different value  every time it run again. And I build the FW from CCS tool)

Peter.

  • Hello Peter,

    The total number of bytes available on a CC2652R flash memory is 360,448 bytes (352 kB where one kB is equal to 1,024 bytes).  Are you using the same devFlashBase and byteCount parameters for each instance of calculateCrc32 to generate the devCrc values?  I would expect the end result to be the same if the flash memory contents have not changed.  Are you saying that there is a difference in CRC values implying a change in the flash memory which you did not expect?  Can you perform a comparison of the entire flash memory area (0x00 to 0x58000) as read before and after programming the device?  Do you get the same value when performing consecutive CRC commands?

    Regards,
    Ryan

  • Hi Ryan,

    I re-build source code without step (8) and it becomes normal. Some update to flash when device reset?

    My test steps are: when I use selected FW (a.bin) to run when previous flashed content is FW (b.bin), it will run through step 1 ~ step 8 (flash new FW).

    Then I use the same FW (a.out) to run again and expect it can quit at step (4). But it run through step 1 ~ step 8. Out of my expectation.

    It seems step (8) will makes some update for the flashed content which used to have devCrc value [Value A] next turn.

    I re-test again: when I use selected FW (a.bin) to run when previous flashed content is FW (b.bin), it will run through step 1 ~ step 7 (flash new FW).

    Then I use the same FW (a.out) to run again and expect it can quit at step (4). Yes it did.

    Regards,

    Peter.

  • If your firmware uses the NV driver then it is possible for this section of flash memory to be modified during run-time, which would cause the CRC to change.  For example, Zigbee projects use NV flash memory to retain important network information and will update the stored frame counter with each device reset.  Thus you would need to modify your CRC function to avoid the NV area in order to achieve your desired application.

    Regards,
    Ryan

  • Hi Ryan,

    I am working on Zigbee FW.

    Any reference info for the 352 kB layout plan? For example, page range for text only, NV flash, CCFG area (last page, 8 kB size), etc.

    Peter.

  • Updated: 0x00000 ~ 0x52000-1 is the text only area.

  • The flash memory layout is determined by the project's command linker (cmd) file and further information is generated and stored in the map file in the output folder after building the project.

    Regards,
    Ryan