• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 52 subscribers
  • Views 537 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

SIMPLELINK-CC2640R2-SDK: OAD Fails CRC check when using a app+stack merged image.

Anthony Wall
Prodigy 70 points
Part Number: SIMPLELINK-CC2640R2-SDK
Other Parts Discussed in Thread: UNIFLASH, CC2640R2F

Hi,

CCS: v9.1.0

Simplelink CC2640R2 SDK: v3.20.00.21

Uniflash: v5.1.0

XDS Emulation Package: v8.3.0

Debug Probe: XDS200

We're currently working with the CC2640R2F on a custom board that implements off-chip OAD based on the simple_peripheral_offchip_oad example from blestack. We have had it working well until it came to trying to create a production hex file where we discovered that the oad image tool post build step was invoking an argument of 1 [Application] and not merging the stack. Original Post build steps are shown below.

${CG_TOOL_HEX} -order MS --memwidth=8 --romwidth=8 --intel -o ${ProjName}.hex ${ProjName}_${ConfigName}.out
${TOOLS_BLE_DIR}/oad/oad_image_tool ccs ${PROJECT_LOC} 1 -hex1 ${ConfigName}/${ProjName}.hex -bdf ${REF_PROJECT_1_LOC}/TOOLS/ccs_compiler_defines.bcfg -hex2 ${REF_PROJECT_1_LOC}/../Bin/Debug/stack_library.hex -o ${PROJECT_LOC}/../Bin/Debug/${ProjName}_oad


After changing this to 3 [App+Stack Merged] we were able to get a successful app+stack merged image that allowed us to create a production hex file via srecord, this file is working fine when flashing directly via Uniflash.

${CG_TOOL_HEX} -order MS --memwidth=8 --romwidth=8 --intel -o ${ProjName}.hex ${ProjName}_${ConfigName}.out
${TOOLS_BLE_DIR}/oad/oad_image_tool ccs ${PROJECT_LOC} 3 -hex1 ${ConfigName}/${ProjName}.hex -bdf ${REF_PROJECT_1_LOC}/TOOLS/ccs_compiler_defines.bcfg -hex2 ${REF_PROJECT_1_LOC}/../Bin/Debug/stack_library.hex -o ${PROJECT_LOC}/../Bin/Debug/${ProjName}_oad

The problem occuring now is that when trying to use the app+stack merged image for OAD it fails the internal flash CRC check in the BIM after copying. The CRC check after the OAD download is correct and checking the CRC of the image in external flash from within the BIM also returns a correct value, the error only when checking the internal flash after the call to Bim_copyImage()

The BIM has not been modified from the example project except for changing the BSP SPI hardware pins to match our custom hardware.

We noticed that even with an arugment of 3 the OAD image tool also produced an application-only OAD image. Using this image works fine and passes all CRC checks without fault.

Is it simply a case of we aren't able to use the app+stack merged image for OAD or are we missing something?

Best Regards,

Anthony

  • 0
    TI__Mastermind 39610 points

    Anthony,

    I've looped in an expert to help assist here. Have you referenced the "creating a production image" section of the SimpleLink Academy here?http://dev.ti.com/tirex/explore/node?node=APgDxfpPQjPebRJTChVmkg__krol.2c__LATEST

  • 0 in reply to Evan W
    Prodigy 70 points

    Hi Evan,

    Thanks for getting in touch.

    We have referenced this section before when we were initially having production image issues. The problem we found was concerning Task 2->Adding OAD to the Application Project->CCS Instructions->Step 7 where the post-build steps are given.

    We are using unsecure OAD with the SPLIT_APP_STACK_IMAGE format and started with the simple_peripheral_oad_offchip example for the CC2640R2F. This project already had the build steps from this section included. If we use those build steps as-is then we are unable to create a valid production image but do receive a valid application OAD image.

    When investigating this we discovered that the ccs ${PROJECT_LOC} 1 arguments for the OAD image tool were the culprit as an argument of 1 here creates an application-only OAD image (this can be seen by invoking the OAD image tool's help argument). This means the production image that is later created via SRecord does not contain the stack library, only the BIM and application. Changing this to an argument of 3 (merged app+stack) solves that and creates a valid single-binary production image.

    Our problem is less so to do with the production image that is created by SRecord but more the OAD binary image. When running the OAD image tool with an argument of 3 it creates both project_oad.bin and project_oad_merged.bin files. Specifically that the former application-only file works fine when transferred over OAD but the latter merged file results in a spinlock as it fails the CRC check after being copied into flash.

    As mentioned before, using the application-only binary for OAD and the merged binary for production is a suitable solution if need be, although we would benefit from having the option to upgrade the stack later down the line.

    Many Thanks,

    Anthony

  • 0 in reply to Anthony Wall
    TI__Genius 14845 points

    Hi Anthony, 

    Have you tried using argument 1 and following the steps in Task 4 of the "BLE Enhanced OAD" to create a production image using the *_oad_merged.bin file?

    Thanks, 
    Elin

  • 0 in reply to Elin W
    Prodigy 70 points

    Hi Elin,

    Thanks for getting in touch but as mentioned before, running the tool with an argument of 1 produces a file called *_oad_merged.bin but it does not actually contain the stack library. I can verify this because the size of the file is 60KB, which is the size of the application only, a merged image is closer to 115KB. The only way that we can get an oad image that contains both the app and stack library is to run the tool with an argument of 3.

    I must urge that our issue is nothing to do with creating a production image. Our issue is that we cannot execute an app+stack merged OAD image that has been transmitted via the OAD protocol because it is failing the CRC checks once copied into internal flash.

    Regards,
    Anthony

  • 0 in reply to Anthony Wall
    Prodigy 70 points

    So after various tests we remembered that we are using the third sector of the external flash to implement a custom backup routine for key application variables..

    This is what was causing the issue as the default OAD implementation stores App+Stack images in the second sector. Given the size of the image this was occupying the third sector also.

    When an OAD occurred we were calling our backup function and in-turn corrupting part of the image, thus resulting in the CRC fail.

    Moving our backup data to a different address fixed the issue.

    Thanks for helping us get to the bottom of this,

    Anthony

  • 0 in reply to Anthony Wall
    TI__Genius 14845 points

    Hi Anthony, 

    I'm glad you found a solution. Thanks for sharing it! 

    Thanks, 
    Elin