• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 58 subscribers
  • Views 2045 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.

CC2650: Debugging CC2650 with Segger Ozone and J-link

Theo Brower
Prodigy 40 points
Part Number: CC2650
Other Parts Discussed in Thread: SEGGER, , CC2630

I'd like to use a J-Link with Segger Ozone to debug Contiki-NG code on a CC2650 launchpad and I haven't been able to step through code. I'm wondering if there are any special settings I need to set in Ozone or elsewhere to make this happen. I've built Contiki with debug symbols and can load the .elf file into Ozone without any problems. I can also download the code into the CC2650, but it does not halt at main and Ozone reports "CPU running". However, the code I loaded is not actually running because I don't get any output on the serial console until I manually reset the CC2650 with hardware button. If I halt the debugger after downloading the code, it is at address 0x1000 3DE2, which doesn't seem to be valid memory.

I've set the CCXXWARE_CONF_JTAG_INTERFACE_ENABLE flag to 1 in Contiki, so all the debug interfaces should be enabled, the CCFG flags should be set as follows:

#define SET_CCFG_CCFG_TI_OPTIONS_TI_FA_ENABLE           0xC5
#define SET_CCFG_CCFG_TAP_DAP_0_CPU_DAP_ENABLE          0xC5
#define SET_CCFG_CCFG_TAP_DAP_0_PRCM_TAP_ENABLE         0xC5
#define SET_CCFG_CCFG_TAP_DAP_0_TEST_TAP_ENABLE         0xC5
#define SET_CCFG_CCFG_TAP_DAP_1_PBIST2_TAP_ENABLE       0xC5
#define SET_CCFG_CCFG_TAP_DAP_1_PBIST1_TAP_ENABLE       0xC5
#define SET_CCFG_CCFG_TAP_DAP_1_WUC_TAP_ENABLE          0xC5

Any ideas on what I can do/check to figure out why debugging isn't working and fix it? I've also tried with a CC2630 on a custom board and have had similar results where the code doesn't run until I manually reset the chip.

Thanks,
Theo

  • 0
    TI__Guru**** 217617 points
    Hi Theo,

    I will try to find an expert who is familiar with this debug tool and can investigate you issue. In the meantime have you spoken with Segger support or gone through their Wiki page?

    www.segger.com/.../
    https://forum.segger.com/
    wiki.segger.com/Main_Page

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Prodigy 40 points
    Hi Ryan,

    I have not contacted Segger about this issue, but I did look through their forum and wiki and didn't find any relevant posts. It seems like Segger expects the debugging to work with J-Link and CCS, so I might download CCS and give it a try later today as a sanity check.

    Theo
  • 0 in reply to Theo Brower
    Prodigy 40 points

    I Installed CCS and downloaded the rfCarrierWave_CC2650_LAUNCHXL_TI example. With CCS I was able to step through the code using the J-Link emulator. I then took the same .out file and imported it into Segger Ozone. After loading, the program was halted at main and I was able to step through the code until the line calling RF_runCmd for CMD_TX_TEST. At that point, the debugger loses control of the execution and if I halt, debugger is at address 0x1000 0486, which is outside of program code. This seems similar to what I see when trying to debug the Contiki code, so I wonder if those two conditions are related. In the rfCarrierWave example, TI-RTOS is just waiting on the semaphore for command completion, so maybe transition into that state causes the debugger to lose track of execution.

    I'm not sure how to explain why Ozone doesn't halt at main after loading Contiki code, though.

  • 0 in reply to Theo Brower
    TI__Guru**** 217617 points
    You aren't going to be able to debug the pre-compiled TI-RTOS library, which is why the debugger "loses control" and halts at unrecognized addresses. But if you set a breakpoint in your application code then it will halt once accessed. Are you experiencing any issues with the example's operation itself?

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Prodigy 40 points
    The example worked fine, so that was a good sanity check that the Ozone+JLink+CC2650 can work well together.

    My main issue was that the Ozone debugger wouldn't halt at main and just go off into the weeds after I loaded my Contiki image. So I compared the entry points being used in the working Ozone example and my Contiki Ozone project. Turns out that the Ozone .jdebug file I was using with Contiki was missing implementations of AfterTargetReset() and AfterTargetDownload(), so the SP and PC were not being set appropriately and that is why there was no halt at main. I think this was because the Ozone project file I was using was created by an older version of Ozone. When I fixed this issue, the program halted as main as expected.

    Now when I try to debug the Contiki-NG coap example client on the CC2650 through ozone, I can step through the first few function calls without issue, but the program seems to go off into the weeds after the MAC name is printed out when I have the debugger attached. It might be some timing issue caused by debugger since this doesn't happen when I run the program without debugger, I'll dig more into it.

    I'll close this issue since I'm up and running with JLink and Ozone.