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.

CC2642R: Usage of AUTHENTICATE_PERSISTENT_IMG flag

Part Number: CC2642R

Hi.

I've been migrating our project (based on simple_peripheral_onchip_oad) to the new SDK 4.40.04.04. The new BIM has the AUTHENTICATE_PERSISTENT_IMG flag enabled by default, however I was unable to get the persistent app to work with this setting. Perviously I simply combined the BIM .hex, persistent app .hex and project _oad.bin files for the complete image. I'm guessing this no longer works, because the persistent app needs to be signed as well. However simply substituting the .hex file with the _oad.bin file for the persistent app does not work because there are overlapping regions with the project _oad.bin file. And the BIM alone with the persistent app does not seem to load either. My guess is that the oad_image_tool writes the signing information for the persistent app to the wrong location. Is there any information on this?

For now I've removed the flag and everything seems to work as before.

Sincerely,

Alex

  • Hi,

    You may want to refer to our documentation.

    By default, AUTHENTICATE_PERSISTENT_IMG is defined in the BIM application. This means the BIM will also check the validity of the persistent application before booting into it. If you don't want to use this feature, then removing the flag is ok.

    Regards,

  • Hi.

    What about the problem that wanting to use the feature, the standard build process does not generate an image that I can use with it?

    Sincerely,

    Alex

  • Hi,

    The BIM needs to be built with the following define "AUTHENTICATE_PERSISTENT_IMAGE". This define already exists in the .opt files for the BIM, however, it is currently disabled by default.

    Regards,

  • Hi.

    Sorry to be annoying about this, but your answer still does not address my original problem. I can't get the signed image for the persistent application to work, because the signing process seems to write its signature in the wrong place. Namely the location where the user application header would be, which then generates errors when merging the images.

    Sincerely,

    Alex

  • Hi Alex,

    Could you specify which SDK you were using before this one?
    Could you please specify your workflow please? Are you merging the binary files before signing them?

    Best regards,

  • Hi.

    I'm merging the signed files generated by the CCS post-build step.

    Previously we were using SDK 4.2. Here after building the BIM, persistent app and our main app projects we merged the resulting BIM hex, persistent app hex and main app _oad.bin file using srec_cat to obtain a test production-image. This worked as expected.

    In SDK 4.4 with enabled AUTHENTICATE_PERSISTENT_IMG flag, since the persistent app image needs to be signed as well I substituted the persistent app hex with the signed _oad.bin file, but srec_cat then fails because of conflicts.

    The same happens for me if I use the OOB simple_peripheral_onchip_oad, persistent app and BIM projects.

    Sincerely,

    Alex

  • Hi again,

    These are important details for investigation, thank you!
    Could you also provide the log / error message outputted by srec_cat?

    Thanks and regards,

  • Hi.

    For the OOB projects calling:

    srec_cat.exe .\bim_onchip_CC26X2R1_LAUNCHXL_nortos_ccs.hex -intel .\ble5_simple_peripheral_oad_onchip_cc26x2r1lp_persistent_app_FlashROM_Release_oad.bin -bin .\simple_peripheral_oad_onchip_CC26X2R1_LAUNCHXL_tirtos_ccs_Release_oad.bin -bin -o image.hex -intel

    results in:

    srec_cat:
    .\simple_peripheral_oad_onchip_CC26X2R1_LAUNCHXL_tirtos_ccs_Release_oad.bin:
    0x00FF: warning: redundant 0x00000000 value (0x43)
    srec_cat:
    .\simple_peripheral_oad_onchip_CC26X2R1_LAUNCHXL_tirtos_ccs_Release_oad.bin:
    0x00FF: warning: redundant 0x00000001 value (0x43)
    srec_cat:
    .\simple_peripheral_oad_onchip_CC26X2R1_LAUNCHXL_tirtos_ccs_Release_oad.bin:
    0x00FF: warning: redundant 0x00000002 value (0x32)
    srec_cat:
    .\simple_peripheral_oad_onchip_CC26X2R1_LAUNCHXL_tirtos_ccs_Release_oad.bin:
    0x00FF: warning: redundant 0x00000003 value (0x36)
    srec_cat:
    .\simple_peripheral_oad_onchip_CC26X2R1_LAUNCHXL_tirtos_ccs_Release_oad.bin:
    0x00FF: warning: redundant 0x00000004 value (0x78)
    srec_cat:
    .\simple_peripheral_oad_onchip_CC26X2R1_LAUNCHXL_tirtos_ccs_Release_oad.bin:
    0x00FF: warning: redundant 0x00000005 value (0x32)
    srec_cat:
    .\simple_peripheral_oad_onchip_CC26X2R1_LAUNCHXL_tirtos_ccs_Release_oad.bin:
    0x00FF: warning: redundant 0x00000006 value (0x52)
    srec_cat:
    .\simple_peripheral_oad_onchip_CC26X2R1_LAUNCHXL_tirtos_ccs_Release_oad.bin:
    0x00FF: warning: redundant 0x00000007 value (0x31)
    srec_cat:
    .\simple_peripheral_oad_onchip_CC26X2R1_LAUNCHXL_tirtos_ccs_Release_oad.bin:
    0x00FF: multiple 0x00000008 values (previous = 0xA4, this one = 0xAB)

    Since calling

    srec_cat.exe .\bim_onchip_CC26X2R1_LAUNCHXL_nortos_ccs.hex -intel .\ble5_simple_peripheral_oad_onchip_cc26x2r1lp_persistent_app_FlashROM_Release.hex -intel .\simple_peripheral_oad_onchip_CC26X2R1_LAUNCHXL_tirtos_ccs_Release_oad.bin -bin -o image.hex -intel

    does not result in any errors, either the oad_image_tool rewrites the header of the persistent app image in the wrong location or I am doing something else wrong.

    Sincerely,

    Alex

  • Hi.

    Apparently it was me doing something wrong. I'm sorry, but it seems I was not dilligent enough in reading the updated procedure steps in the user guide for on-chip OAD, where it is clearly mentioned that the signed persistent app image needs to be offset manually to the correct position in the flash. Adding the offset fixes the problem and everything works as expected.

    Thank you for your help and again sorry.

    Sincerely,

    Alex

  • Hi Alex,

    No need to apologize. Thank you for sharing the solution.

    Best regards,