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.

Frontier Tool / Porting to BLE Stack 2.2

Other Parts Discussed in Thread: CC2650

Hello,

while porting a BLE client application for the cc2650 from BLE Stack 2.1 to 2.2 I’ve stumbled over one detail, I found no solution for, up to now. Both projects (application and stack) are now ported and they compile, but I have a problem with the final linker step. The app and stack collide. The stack project is ported to use the frontier tool and the frontier tool is running without error as post build step to the stack project. This is the result of the frontier tool:
--define=ICALL_STACK0_ADDR=0xf001
--define=ICALL_STACK0_START=0xf000
--define=ICALL_RAM0_START=0x20004368
If I got it right, STACK0_ADDR is most likely the address of the dispatch function used by the app to dispatch function calls to the stack: STACK0_START is the start address of the stack in flash. When I link the stack again, I get following memory usage and start addresses:
         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  FLASH                 00000000   0001f000  0000fc60  0000f3a0  R  X
  SRAM                  20000000   000048e7  0000057c  0000436b  RW X
And when I link then an application image:
         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  FLASH                 00000000   0000f000  0000effa  00000006  R  X
  FLASH_LAST_PAGE       0001f000   00001000  00001000  00000000  R  X
  SRAM                  20000000   00004368  00003d3c  0000062c  RW X
There is apparently something wrong. The sum of both flash lengths should be 0x20000 and not both images should start at address 0. The section layout of the application seems to reflect the result of the frontier tool. The image starts at 0 and ends with the start of the stack image. But the image layout of the stack image does not. This is the linker call (formatted for readability):
'Invoking: ARM Linker'
"C:/ti/ccsv6/tools/compiler/ti-cgt-arm_5.2.6/bin/armcl" 
    --cmd_file="C:/ti/simplelink/ble_sdk_2_02_00_31/src/config/build_components.opt" 
    --cmd_file="C:/Users/Torsten/rcp_server/rcp_server_stack/../Config/buildConfig.opt"  
    -mv7M3 --code_state=16 --abi=eabi -me -O4 --opt_for_speed=0 --c99 
    --define=USE_ICALL 
    --define=OSAL_SNV=1 
    --define=FLASH_ROM_BUILD 
    --define=POWER_SAVING 
    --define=GATT_NO_CLIENT 
    --define=INCLUDE_AES_DECRYPT 
    --define=xPM_DISABLE_PWRDOWN 
    --define=xTESTMODES 
    --define=xTEST_BLEBOARD 
    --define=OSAL_CBTIMER_NUM_TASKS=1 
    --define=xDEBUG 
    --define=EXT_HAL_ASSERT 
    --define=xDEBUG_GPIO 
    --define=xDEBUG_ENC 
    --define=xDEBUG_SW_TRACE 
    --define=NEAR_FUNC= 
    --define=DATA= 
    --define=CC26XXWARE 
    --define=CC26XX 
    --diag_wrap=off --diag_suppress=48 --diag_suppress=16004 --display_error_number --diag_warning=225 
    -z -m"rcp_server_stack.map" --heap_size=0 --stack_size=256 
    -i"C:/ti/ccsv6/tools/compiler/ti-cgt-arm_5.2.6/lib" 
    -i"C:/ti/ccsv6/tools/compiler/ti-cgt-arm_5.2.6/include" 
    --reread_libs 
    --display_error_number 
    --diag_wrap=off 
    --warn_sections 
    --diag_suppress=16002-D 
    --diag_suppress=10247-D 
    --diag_suppress=10325-D 
    --diag_suppress=10229-D 
    --xml_link_info="rcp_server_stack_linkInfo.xml" 
    --entry_point=startup_entry --rom_model --compress_dwarf=on 
    --unused_section_elimination=on 
    -o "rcp_server_stack.out" "./TOOLS/onboard.obj" "./Startup/ble_user_config.obj" "./Startup/common_rom_init.obj" "./Startup/icall_startup.obj" "./Startup/osal_icall_ble.obj" "./Startup/rom_init.obj" "./PROFILES/gap.obj" "./PROFILES/gapbondmgr.obj" "./PROFILES/gattservapp_util.obj" "./OSAL/osal.obj" "./OSAL/osal_bufmgr.obj" "./OSAL/osal_cbtimer.obj" "./OSAL/osal_clock.obj" "./OSAL/osal_memory_icall.obj" "./OSAL/osal_pwrmgr.obj" "./OSAL/osal_snv_wrapper.obj" "./OSAL/osal_timers.obj" "./NPI/npi.obj" "./ICallBLE/ble_dispatch.obj" "./HAL/Target/CC2650/_common/mb_patch.obj" "./HAL/Target/CC2650/Drivers/hal_flash_wrapper.obj" "./HAL/Target/CC2650/Drivers/hal_rtc_wrapper.obj" "./HAL/Target/CC2650/Drivers/hal_trng_wrapper.obj" "./HAL/Common/hal_assert.obj" 
    "C:/ti/simplelink/ble_sdk_2_02_00_31/src/common/cc26xx/ccs/cc26xx_stack.cmd" 
    "C:/Users/Torsten/rcp_server/Config/ccsLinkerDefines.cmd" 
    "C:/Users/Torsten/rcp_server/Config/lib_linker.cmd"  
    -l"libc.a" 
    -lC:/Users/Torsten/rcp_server/rcp_server_stack/../Config/lib_linker.cmd 
    -l"C:/ti/simplelink/ble_sdk_2_02_00_31/src/rom/enc_lib/cc26xx_ecc_rom_api.a" 
    -l"C:/ti/simplelink/ble_sdk_2_02_00_31/src/rom/ble_rom_releases/04242014/ble_rom_patch.symbols" 
    -lC:/ti/tirtos_cc13xx_cc26xx_2_18_00_03/products/cc26xxware_2_23_03_17162/driverlib/bin/ccs/driverlib.lib 
This is the call to the frontier tool:
C:/ti/simplelink/ble_sdk_2_02_00_31/tools/frontier/frontier.exe 
    ccs 
    C:/Users/Torsten/rcp_server/rcp_server_stack/FlashROM/rcp_server_stack_linkInfo.xml 
    C:/Users/Torsten/rcp_server/rcp_server_stack/../Config/ccsCompilerDefines.bcfg 
    C:/Users/Torsten/rcp_server/rcp_server_stack/../Config/ccsLinkerDefines.cmd
' '    
What am I’m missing here? Any pointers? 
Thanks in advance and kind regards,
Torsten
Edit: Sorry, I was using the plain text editor and that swallowed all formatting and I was sitting in a train with bad internet connectivity.

  • Have you compared this to a working 2.2.0 project such as simpleBLEPeripheral?
  • Hi,

    I think I bumped into the same issue. It looks like it is due to an incorrect link order. According to your log, cc26xx_stack.cmd is linked before ccs_linker_defines.cmd. Yet, the defines in ccs_linker_defines.cmd are required by cc26xx_stack.cmd. 

    I've tried setting the link order in properties/build/Link Order, but it has no effect on my linker command. It looks like there is a bug in CCS.

    If you found a way to fix the link order, I'd be interested.

    Best regards,

    Valerian

  • Sorry for not replying! (the notification is not working for me). I was confused by the identical starting addresses, but it all just boiled down to running out of flash after the porting. More aggressive optimization fixed that issue.

    Thank you.