• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 51 subscribers
  • Views 277 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.

CC2340R5: CCFG difference cause application not to start with custom bootloader

Savas Sahin
Prodigy 240 points

Part Number: CC2340R5
Other Parts Discussed in Thread: UNIFLASH, SYSCONFIG

Hi, 

We are using CC2340R5 data_stream example as applicaiton for our product base and we are using our custom bootloader. We update files using bootloader we verified that we are correctly writing to flash. and we are sure Bootloader Jumps correctly. We think difference in CCFG cause this problem. As we checked from refrence manual, difference might be .pAppVtor  param. 

Here is the scenarios, we face:

When we flash device using Uniflash with: 
 - boot.bin + app.bin + ccfg_boot.bin , bootloader works but jumping to applicaiton does not start app to run.

When we flash device using Uniflash with: 
 - boot.bin + app.bin + ccfg_app.bin ,both bootloader and app works once after power reset it seems bootloader does not working as a consequence app is not starting. 

After debugging in CCS v20 ; we realized that ccfg_boot and ccfg_app are different. I attached the files for ccfg_boot and ccfg_app taken from memory browser of CCS. Also attached cmd files of the projects.

We are using simplelink_lowpower_f3_sdk_9_11_00_18,
CCS Version: 20.2.0.12__1.8.0

Compilier TI CLANG 4.0.3 LTS

artFiles.rar 


Waiting your response, as the problem is urgent.
Thank you,

All the bests

Savas

  • 0
    TI__Guru**** 223757 points

    Hi Savas,

    Savas Sahin said:
    When we flash device using Uniflash with: 
     - boot.bin + app.bin + ccfg_app.bin ,both bootloader and app works once after power reset it seems bootloader does not working as a consequence app is not starting. 

    This could be the application running once with the bootloader being bypassed from Uniflash programming, but bootloader entry fails after device restart.

    Savas Sahin said:
    When we flash device using Uniflash with: 
     - boot.bin + app.bin + ccfg_boot.bin , bootloader works but jumping to applicaiton does not start app to run.

    It sounds like the bootloader is not properly jumping to the application start.  Are you basing your custom bootloader from the MCUBoot example?  The command linker files (*.cmd) seem to originate from a BLE OAD example, and I don't know which definitions apply to your projects.  I noticed the .cmd files are hardly any different which is unexpected for a boot + app configuration.  The bootloader (taking MCUBoot as the example) typically exists from flash memory 0x0 to ~0x6000 and includes the CCFG (SysConfig -> Device Configuration) as it should start on device power up.  A hex image is generated in the CCS -> Project Properties -> Build -> Steps -> Post-build steps to include both the bootloader and CCFG in a single file:

    C:/ti/ti-cgt-armllvm_4.0.2.LTS-0/bin/tiarmhex -order MS --memwidth=8 --romwidth=8 --intel -o mcuboot_LP_EM_CC2340R5_nortos_ticlang.hex mcuboot_LP_EM_CC2340R5_nortos_ticlang

    The application .cmd should offset the flash writing by starting at the end address of the bootloader (ex. 0x6000) and post-build a binary image that does not include the CCFG:

    C:/ti/ccs2040/ccs/tools/compiler/ti-cgt-armllvm_4.0.4.LTS/bin/tiarmobjcopy basic_ble_oad_offchip_LP_EM_CC2340R5_freertos_ticlang.out --output-target binary basic_ble_oad_offchip_LP_EM_CC2340R5_freertos_ticlang_noheader.bin --remove-section=.ccfg

    Then in Uniflash you would make sure to select "0x6000" as the start address of the application binary image, which is where the bootloader should be jumping to when it is ready to start the application (or however your CCFG is configured, as the OAD examples include headers for each image).  You use case is most similar to the basic_ble_oad_offchip example and may be able to provide you with some helpful pointers (in conjunction with MCUBoot).

    To re-iterate, you can review the SysConfig -> Device Configuration to determine the differences between your CCFGs (except for the .bootCfg which should only be the 

    BLE OAD Fundamentals SLA
    Add BLE OAD to Basic Example SLA
    BLE5-Stack MCUboot OAD Guide

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 240 points

    Hi Ryan,

    After some debuging and trailing some. I realized that Power_init function is totally preventing a healty jump in RTOS bootloader case.

    So i did not use it in the bootloader and than open it in the application side. Everything is now seems fine.

    Now i have another question for you. 

    After i debug application alone, and stop debugging and do a hard reset( simply just closing power supply and enabling it,  i realized that applicaiton is starting even there is no booloader in the flash. How is that happening ? Does default FCFG bootloader checks for addresses if thee is valid data?

    BOOT AREA : 0x0 - 0x7FFFF all the values are 0xFF, i checked with memory browser on uniflash
    APP AREA : 0x8000 - Rest of the FLash 

    My BOOT configuration in the sysconfig file:

       - APP Vector table: resetVectors 

       - BOOT Configuration :DEfault FCFG Bootloader

  • +1 in reply to Savas Sahin
    TI__Guru**** 223757 points

    The ROM serial bootloader will not be entered unless the backdoor bootloader pin is active upon reset, and even then this bootloader would not know to jump to your applications.  The behavior you've described sounds like the application's CCFG is being programmed instead of your custom bootloader's, as accomplished by the CCS flasher, in which case the CCFG's .bootCfg.pAppVtor is pointing to your application's resetVectors instead of the bootloader.  As I mentioned before, the application's CCFG information should not be programmed as the custom bootloader's version needs to be retained instead.  So the SysConfig file you are mentioning for the Device Configuration should be that of the bootloader's, as that is the only CCFG which should be programmed.  This is accomplished by programming a bootloader hex image which contains the bootloader application and CCFG, along with an application binary image which does not have the CCFG included, in Uniflash.  In this case the instructions and guides I provided in my previous reply should be helpful.

    Regards,
    Ryan