• State TI Thinks Resolved
  • Locked Locked
  • Replies 16 replies
  • Answers 5 answers
  • Subscribers 55 subscribers
  • Views 1094 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CCS/LAUNCHXL-CC1310: Cannot debug Contiki-NG Launchpad solution

Simon Lightbody
Prodigy 110 points
Part Number: LAUNCHXL-CC1310
Other Parts Discussed in Thread: CC1310

Tool/software: Code Composer Studio

I have setup a project in Code Composer following the instructions near the end of the page here .

After building, I can launch a debug session using the .elf file for the cc26x0-web-demo found in examples/platform-specific/cc26x0-cc13x0/cc26x0-web-demo/build/cc26x0-cc13x0/launchpad/cc1310 and it runs to main().

But, if I then continue execution, the debugger no longer seems to be able to break the code and the code is not executing properly as the LED on the Launchpad is not blinking.

Pulling the USB connector out of the Launchpad and then re-plugging, the code seems to run fine (LED is blinking), so this seems to be related to the debugging process.

After stepping through the code, it appears that misoperation begins when the interrupts are re-enabled in this call in soc_rtc_init()

/* Re-enable interrupts */
  if(!interrupts_disabled) {
    ti_lib_int_master_enable();

I do not understand why the code appears to run fine when not trying to debug, but misoperates when debugging.

Any help is appreciated.

  • 0
    TI__Mastermind 25810 points

    Hey Simon,

    Please allow me some time to find the expert to assist you with this.

    In the meantime, take a look at the following related post as it may provide some insight: https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz/f/156/t/638371.

  • 0
    TI__Mastermind 23730 points

    Hi Simon,

    Could you try the following and see if this helps:

    After starting the debugger session and halting in main(), do a Board Reset by clicking

    • Run -> Reset -> Board Reset (automatic connect/disconnect)

    Then issue a restart

    • Run -> Restart

    You should now be back in main() again. Try to run a as normal.

  • 0 in reply to Severin Suveren
    Prodigy 110 points

    No, sorry, that did not help. After completing your steps, I seemed to be stopped at the ResetISR()

    I then hit the Resume button and then all except the Terminate button became greyed out and the board was not executing (no LED blinking.)

  • 0 in reply to Ammar N
    Prodigy 110 points

    Based on this advice, I tried taking the "hello_world" ccs example project and then changing the project .out reference to the .elf file generated by my Contiki build. I also removed the hello_world .c files from the project and referenced the contiki_main.c. Then, I prevented the hello_world project from building and just used it to debug. I encounter the same problem as with my original project. Attempting to step past approximately the end of the soc_rtc_init() function (where it renables interrupts) results in ccs not breaking and hitting break shows the PC at location 0x100035fc. Once again, pulling the USB cable out of the launchpad and replugging, the LED starts blinking indicating the Contiki code is running normally. (Re-starting the debug session in ccs and just hitting resume from the start of main does not result in code operation.)

  • 0 in reply to Simon Lightbody
    TI__Mastermind 23730 points

    Have you tried disabling the Watchdog? The watchdog on CC1310 does not properly pause during debugging, and so I've personally experienced that sometimes I need to completely disable the Watchdog when debugging on CC1310.

  • 0 in reply to Severin Suveren
    Prodigy 110 points

    Not sure how the watchdog on/off is controlled on this chip, but it appears that the Contiki code configures the watchdog much later in the initialization than I am having the problem at...

    #if PLATFORM_MAIN_ACCEPTS_ARGS
    main(int argc, char **argv)
    {
      platform_process_args(argc, argv);
    #else
    main(void)
    {
    #endif
      platform_init_stage_one();

      clock_init();
      rtimer_init();
      process_init();
      process_start(&etimer_process, NULL);
      ctimer_init();
      watchdog_init();

    Is there a way I can tell if the watchdog is somehow enabled before (in platform_init_stage_one()?)

  • 0 in reply to Simon Lightbody
    TI__Mastermind 23730 points

    Watchdog is disabled by commenting out the watchdog_init() line. However, if it crashes before that line executes then it probably isn't the watchdog.

    It is hard to say what the problem is. I just followed the guide again, and was able to debug a CC1310 LaunchPad without any problem. Could you please try to redo the project once more. You could also try out the simplelink platform instead of cc26x0-cc13x0 platform.

  • 0 in reply to Severin Suveren
    Prodigy 110 points

    Just looking back through the thread and decided to try this again. The behaviour was a little different than before. When I do Run->Reset->Board Reset(automatic connect/disconnect) and then continue execution, the LED does start blinking on the Launchpad, but if I then Suspend, I end up in the lpm_sleep() function and soon after the resume and suspend icons become greyed out leaving the only option as Terminate.

  • 0 in reply to Simon Lightbody
    Prodigy 110 points

    Just did a bit more experimenting and it seems that the Contiki code is still turning on the watchdog despite WATCHDOG_CONF_DISABLE being set to 1 in project-conf.h

    Now the procedure where I download, stop at main(), then Run->Reset->Board reset, then run works and I can suspend and resume code execution ok.

    So, now the only question is why is the extra Run->Reset->Board reset required? I still can't just run from the start of main successfully and cannot debug the startup of the code.

  • 0 in reply to Simon Lightbody
    TI__Mastermind 23730 points

    WATCHDOG_CONF_DISABLE is only available for the simplelink target. cc26x0-cc13x0 target does not support that configuration flag.

    You describing that doing a board reset and then running seems to indicate that it is properly running now. And, when pausing and being in lpm_sleep() is to be expected as you are pausing execution while the device is in standby. However, this probably causes the watchdog to time out and cause the debug session to crash.

    In order to disable the watchdog with the cc26x0-cc13x0 target, you need to comment out the watchdog_init() function call in main().

  • 0 in reply to Severin Suveren
    Prodigy 110 points

    Yes, I did that. So, now my only remaining question is as above "So, now the only question is why is the extra Run->Reset->Board reset required?"

    If I don't do this after starting the debug session, the original problem still occurs. I would like to understand why this is happening.

    Note, I am also seeing weird problems where if I try to set a breakpoint on a particular line of c code, a breakpoint gets set in a completely different area of code (often in a different c source file) - in case this is related.

  • 0 in reply to Simon Lightbody
    TI__Mastermind 23730 points

    I don't have a good answer for why it is needed. I think the debug session is missing some configurations as part of creating a new one from scratch, but I have been unable to figure out what is missing.

  • 0 in reply to Severin Suveren
    Prodigy 110 points

    Ok, let me know when you have an idea. I am still getting the weird behaviour when attempting to set breakpoints. Not sure if this only happens when the code I attempt to set a breakpoint on is not part of the in scope compiled code or not.

  • 0 in reply to Simon Lightbody
    TI__Mastermind 23730 points

    Simon,

    It is still unclear whether you have disabled watchdog or not. If the debug sessions falls apart when breaking on a breakpoint would indicate that the watchdog is still running and causing a reset.

  • 0 in reply to Severin Suveren
    Prodigy 110 points

    Yes watchdog is disabled. So, 2 issues remain:

    1) I don't understand why the extra reset is required after starting the debug session to allow proper debugging to happen.

    2) As I am unfamiliar with the Contiki code and it has many pieces of code that may or may not be part of the project and that is controlled by #defines in many and varied header files, it is difficult to know if any given code segment is actually compiled into a given image. Therefore, it appears that if you try to set a breakpoint on a line that is not part of the project, a breakpoint sometimes gets set in some random other part of the code with no error message indicating there was a problem. Other times, there is an indication that it is not possible to set a breakpoint at that location.

  • 0 in reply to Simon Lightbody
    TI__Mastermind 23730 points

    1) As I said before, I don't have a good answer for why this is the case, nor a better solution as of now other than doing a manual board reset after starting a debug session.

    2) That is how debugging in general works with CCS, and is not specific for Contiki-NG. If a piece of code is not compiled in and you try to set a breakpoint, then CCS will usually try to set a breakpoint to the closest symbol in that function. This can depend on multitude of things, such as compile flags, available debug information (is code compiled with debug symbols -g?), optimization level used, is the source file correctly linked to the compiled debug information, etc. You can see whether CCS was successful to set a breakpoint if the breakpoint symbol itself is blue-ish in color. If it is greyed out, then CCS was not successful for some reason.