CC1352R: Can't flash a BLE OAD Production Image

Jo Gelie

Part Number: CC1352R
Other Parts Discussed in Thread: UNIFLASH

Hi Expert,

Setup:

SDK: simplelink_cc13xx_cc26xx_sdk_5_30_01_01
Uniflash: 7.0.0.3615
Devices: LPSTK-CC1352R1F3
XDC Tools: 3.62.1.16
Compiler: ti-cgt-arm_20.2.5.LTS

I followed the instructions for building and loading an OAD image by flashing the BIM bim_offchip_CC1352R1_LAUNCHXL_nortos_ccs.hex (debug unsecure) and the *.bin generated by oad_image_tool.exe:

${CG_TOOL_HEX} -order MS --memwidth=8 --romwidth=8 --intel -o ${ProjName}.hex ${ProjName}
${COM_TI_SIMPLELINK_CC13XX_CC26XX_SDK_INSTALL_DIR}/tools/common/oad/oad_image_tool --verbose ccs ${PROJECT_LOC} 7 -hex1 ${ConfigName}/${ProjName}.hex -k ${COM_TI_SIMPLELINK_CC13XX_CC26XX_SDK_INSTALL_DIR}/tools/common/oad/private.pem -o ${ConfigName}/${ProjName}

However, with both Uniflash and Jlink, the device does not boot, despite:

1) Flash Verification OK

[SUCCESS] Cortex_M4_0: Program verification successful for Multiple Files

2) Image header OK

The image header looks good since informations exposed by oad_image_tool:

____________________________
       OAD IMG HDR
____________________________
Field       |    Value
imgID       |    b'CC13x2R1'
CRC         |    0x62EDF26E
bimVer      |    3
metaVer     |    1
techType    |    0xFFFE
imgCpStat   |    0xFF
crcStat     |    0xFF
imgType     |    0x7
imgNo       |    0x0
imgVld      |    0xFFFFFFFF
len         |    0x3F8D4
prgEntry    |    0xCC
softVer     |    0x31303030
imgEndAddr  |    0x3F8D3
hdrLen      |    0x2C
 

}

are present within the beginning of the *.bin:

Note 1: Also, I don't have any issue while flashing the *.out with Uniflash.

Note 2: The option 'Keep CCFG' is unchecked.

Questions:

So, if both image header and flash verification are correct, what could explain the fact the device does not boot while flashing the BIM.hex and *.bin?
Is there a way to retrieve the boot failure? bootloader verbose message? others,.
Is there a tool for verifying *.bin integrity, to ensure that the binary is not corrupted?

Thanks,

over 2 years ago

0 AndresM over 2 years ago

TI__Expert 3886 points

Hi Jo,

I've assigned this thread to someone. They should reply shortly.

BR,
Andres

0 Jo Gelie over 2 years ago in reply to AndresM

Intellectual 570 points

Hi,

While carefully looking at the memory map, I noticed that the vector table is mapped @ 0x0090.:

SECTION ALLOCATION MAP

 output                                  attributes/
section   page    origin      length       input sections
--------  ----  ----------  ----------   ----------------
.image_header 
*          0    00000000    0000008d     
                  00000000    0000008d     oad_image_header_app.obj (.image_header:retain)

.resetVecs 
*          0    00000090    0000003c     
                  00000090    0000003c     mioty_pem4f.oem4f (.resetVecs)

.intvecs   0    000000cc    00000000     UNINITIALIZED

However, the program entry point (prgEntry) specified within the .image_header and used by the BIM equal to 0x00cc which corresponds to the .intvecs:

____________________________
       OAD IMG HDR
____________________________
Field       |    Value
imgID       |    b'CC13x2R1'
CRC         |    0x62EDF26E
bimVer      |    3
metaVer     |    1
techType    |    0xFFFE
imgCpStat   |    0xFF
crcStat     |    0xFF
imgType     |    0x7
imgNo       |    0x0
imgVld      |    0xFFFFFFFF
len         |    0x3F8D4
prgEntry    |    0xCC          // <- it should be 0x90 for the .resetVecs
softVer     |    0x31303030
imgEndAddr  |    0x3F8D3
hdrLen      |    0x2C

In fact, the linker script exposes the symbol prgEntryAddr at the address of .intvecs instead of .resetVecs.

  GROUP > ENTRY
  {
    .resetVecs  
    .intvecs        LOAD_START(prgEntryAddr)
    EntrySection
  }

As a result, instead of jumping at the interrupt vector table ( .resetVecs), the device jumps at intvecs (which is not used by CCS compiler).

So for fixing my problem, I modified the linker script COM_TI_SIMPLELINK_CC13XX_CC26XX_SDK_INSTALL_DIR\source\ti\ble5stack\common\cc26xx\ccs\cc26x2_app_oad_agama.cmd as follow:

  GROUP > ENTRY
  {
    .resetVecs  LOAD_START(prgEntryAddr)
    .intvecs
    EntrySection
  }

Could you please confirm?

Thanks

0 Marie H over 2 years ago in reply to Jo Gelie

TI__Guru* 77291 points

Hi Jo,

I don't recognize the code snippet you posted. Per default this is the code snippet in the SDK:

  GROUP > ENTRY
  {
    .resetVecs
    .intvecs
    EntrySection  LOAD_START(prgEntryAddr)
  }

Cheers,

Marie H.

0 Jo Gelie over 2 years ago in reply to Marie H

Intellectual 570 points

Hi Marie,

Thanks for your contribution, it's just a wrong copy paste.

My point is that prgEntryAddr does not represent .resetVecs but .intvecs address and for any reason, my OAD project have the following memory mapping:

.resetVecs @ 0x90

.intvecs @ 0xCC

prgEntryAddr @ 0xCC

SECTION ALLOCATION MAP

 output                                  attributes/
section   page    origin      length       input sections
--------  ----  ----------  ----------   ----------------
.image_header 
*          0    00000000    0000008d     
                  00000000    0000008d     oad_image_header_app.obj (.image_header:retain)

.resetVecs 
*          0    00000090    0000003c     
                  00000090    0000003c     mioty_pem4f.oem4f (.resetVecs)

.intvecs   0    000000cc    00000000     UNINITIALIZED

EntrySection 
*          0    000000cc    00000000     UNINITIALIZED

As a result instead of jumping at 0x90 (.resetVecs), the bootloader loads the application at .intvecs (0xCC) leading to a crash.

My solution was to modify the linker script in order to set prgEntryAddr address at .resetVecs location.

Also the dmm_wsnnode_ble_sp_oad_app_CC1352R1_LAUNCHXL_tirtos_ccs project contains 2 .resetVecs sections:

The first one @ 0x90 with a length of: 0x3C
The 2nd one (also) @ 0x90 with a length of 0x00 following by both the .intvecs and EntrySection

SECTION ALLOCATION MAP

 output                                  attributes/
section   page    origin      length       input sections
--------  ----  ----------  ----------   ----------------
.data:xdcRomConstPtr 
*          0    20000100    00000004     UNINITIALIZED
                  20000100    00000004     ble_oad_release_pem4f.oem4f (.data:xdcRomConstPtr)

.data:xdcRomExternFuncPtr 
*          0    20000104    00000004     UNINITIALIZED
                  20000104    00000004     ble_oad_release_pem4f.oem4f (.data:xdcRomExternFuncPtr)

.data:xdcRomStatePtr 
*          0    20000108    00000004     UNINITIALIZED
                  20000108    00000004     ble_oad_release_pem4f.oem4f (.data:xdcRomStatePtr)

.bootVecs 
*          0    00000000    00000008     DSECT
                  00000000    00000008     boot.aem4f : boot.oem4f (.bootVecs)

.resetVecs 
*          0    00000090    0000003c     
                  00000090    0000003c     ble_oad_release_pem4f.oem4f (.resetVecs)

.vecs      0    20000000    000000d8     NOLOAD SECTION
                  20000000    000000d8     ble_oad_release_pem4f.oem4f (.vecs)

xdc.meta   0    00000000    00000122     COPY SECTION
                  00000000    00000122     ble_oad_release_pem4f.oem4f (xdc.meta)

xdc.noload 
*          0    00000000    00000000     COPY SECTION

.image_header 
*          0    00000000    0000008d     
                  00000000    0000008d     oad_image_header_app.obj (.image_header:retain)

.resetVecs 
*          0    00000090    00000000     UNINITIALIZED

.intvecs   0    00000090    00000000     UNINITIALIZED

Question (please answer):

What's the module responsible for creating 2 .resetVecs at the same address (0x90) but with different lengths (respectively 0x3C and 0x00)?

Thanks

0 Marie H over 2 years ago in reply to Jo Gelie

TI__Guru* 77291 points

Hi Jo,

Sorry for the delay.

I just built the simple_peripheral project from the SDK 5.30 (simple_peripheral_oad_offchip_CC13X2R1_LAUNCHXL_tirtos_ccs). This is the map file code snippet. As you can see, it's different from your file:

.image_header 
*          0    00000000    0000008d     
                  00000000    0000008d     oad_image_header_app.obj (.image_header:retain)

.resetVecs 
*          0    00000090    00000000     UNINITIALIZED

.intvecs   0    00000090    00000000     UNINITIALIZED

EntrySection 
*          0    00000090    00000000     UNINITIALIZED

Which OAD project are you basing your code on?

Cheers,

Marie H

Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

Sub-1 GHz

Sub-1 GHz forum

CC1352R: Can't flash a BLE OAD Production Image