• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 54 subscribers
  • Views 182 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.

Launchpad CC2652-R7, CODECOMPOSER: CCS 12.8.1 - Getting Started - Debugging Questions

Damon Stewart
Prodigy 110 points

Part Number: Launchpad CC2652-R7

Tool/software: CODECOMPOSER

Hello,

I am new to TI and have a couple general "getting started" questions with Code Composer Studio v12.8.1.  I developed a simple application on the Launchpad CC2652-R7 development board that is based off a "DMM ZR Light" demo application that uses Zigbee and Bluetooth.  When I debug the program, it runs fine the first time.  But after that:

1. If I click the "Restart" button, the application doesn't restart properly.  From what I can tell, it appears to assert.  Is this expected behavior for a sample application, or is it possible I broke something?  Why would it assert on a restart?  Is there anything I need to configure to get the "Restart" debugger option to work correctly?

2. During development, I have occasionally hit an assert for one reason or another.  When that happens, on other platforms, I can inspect the callstack or registers and get an idea of what code was running when the assert happened.  However, on this platform, the callstack and registers are not helpful.  There are about 5 different functions that were all part of the assert, so there is no clue where the assert was called from, as shown in the image below.  Is there any good way to figure out what function called the assert?

3. If I power cycle the board, it runs an old (default) application that is not the application I was debugging with.  Similarly, if I load the compiled .out image using Uniflash, then my application runs fine.  But if I click the "Verify Image" button in UniFlash, or power cycle the target, then it runs the default application - not my compiled and loaded application.  Does the Launchpad come installed with a Boot Image Manager?  Could that be loading the default application?  When I run the debugger or flash the .out file, is it running the image out of RAM and not flash?  Is there something I need to change in my project so it can work with the bootloader, and run after a power cycle?

Thanks in advance!

  • 0
    TI__Guru**** 458351 points

    Hello,

    Damon Stewart said:

    1. If I click the "Restart" button, the application doesn't restart properly.  From what I can tell, it appears to assert.  Is this expected behavior for a sample application, or is it possible I broke something?  Why would it assert on a restart?  Is there anything I need to configure to get the "Restart" debugger option to work correctly?

    Note that the "restart" feature simply sets the program counter (PC) to the entry point of the application. Since the default behavior of the debugger is to auto-run to main (or specified label) on a reload or restart, the debugger usually tries to run to main after a restart. It looks like it is hitting an exception before it can get to main. 

    Is this expected? Well, it depends on the target and application. Some targets needs some additional configuration to run properly. For example, there are some targets where after you run an example application once, you need to do a system reset before you can restart the program and run successfully. I don't know enough about your target an application to know if what you are observing with the restart behavior is expected or not. I will bring this thread to the device experts to comment further.

    Thanks

    ki

  • 0
    TI__Guru**** 215077 points

    Hello Damon,

    Ki said:
    Note that the "restart" feature simply sets the program counter (PC) to the entry point of the application

    1. This is an issue for the radio core which does not understand the simple PC reset, thus a hardware assertion is guaranteed to occur especially with radio-enabled examples using the CCS debugger restart feature.  I recommend that you re-load the application (does not require restarting the debugger) as this will restart the SimpleLink CC2652R7 in a safe debug state.

    2. TI offers a Debugging Guide to help navigate common issues such as hardware asserts, and the RTOS Object Viewer (ROV) could help provide additional clues, otherwise there are a multitude of assert reasons so I would ask for you to clarify what operations or code implementations are likely to cause the issue to appear.

    3. The LaunchPad does have the BIM installed by default for the pre-loaded project_zero example (just BLE, no Zigbee), but this would be erase or overwritten with most programming operations.  Are you using the OAD version of the DMM ZR light project?  If so then you will need to load the BIM and application images together using Uniflash.  Do you have a valid candidate image stored in external flash?  Otherwise I will need to further understand how the newer binary image is not overwriting the older version in main flash.  By default, the CCS debugger only overwrites necessary sectors, however flashing the .out file certainly runs from flash. There is a question of how the BIM interprets candidate images during boot, which is subverted if loading an image with the CCS Debugger.  Debugging OAD environments can be quite tricky, here is a SimpleLink Academy Lab which covers some instructions you might find useful.

    Regards,
    Ryan