Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

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

LAUNCHXL-CC1352R1: Reset both cores with OpenOCD

Jose Simoes
Intellectual 460 points
Part Number: LAUNCHXL-CC1352R1

Hi,

I'm working on project for this part in VS Code and flash/debug using OpenOCD.

I've noticed on the OpenOCD output the following message:

Warn : Only resetting the Cortex-M core, use a reset-init event handler to reset any peripherals or configure hardware srst support.

Which seems to be accurate because after that, some calls to the radio API hang. From what I understood from the part manual this is caused by the radio core being in a unknow state. If I manually reset the board and after that start the debug, those hangs do not happen. This is consistent with the explanation and makes sense.

Now, if I use Code Composer to flash and start debug of one of the sample projects, it launches the debugger just fine. No need to manually reset the board.

I did notice on the CCS output the following message:

Cortex_M4_0: GEL Output: Board Reset Complete.

This leads me to think that the OpenOCD configuration files for the CC13x2/26xx are missing _that_ board reset.

Can you please confirm the above, what could be missing and/or any extra arguments that should be added to the command line launching OpenOCD?

Thanks!

  • 0
    TI__Intellectual 2515 points

    "Board Reset" is the term CCS uses for a reset done by asserting the nSRST pin of the JTAG header. (It's not called System Reset because the name already had a couple other uses, either the reset done via the ICEPick JTAG router hardware or the Cortex M system reset via the AIRCR).

    What version of OpenOCD are you using?  It looks like the version you're using is defaulting to using the vector reset to reset the Cortex M core. To do the equivalent of the board reset, you would need to use the nSRST pin.  The following could be added to the target config file:

    reset_config srst_only
    adapter_nsrst_delay 100

    However, the last official release of OpenOCD (0.10.0) has a bug in the reset handling, and this won't work for the CC13xx/CC26xx targets.  (It pulls the reset once, re-runs the code needed to enable JTAG, then pulls reset again leaving the target in an undebuggable state.)

    We have a work around in a copy of OpenOCD we maintain at https://git.ti.com/sdo-emu/openocd. And in this version, we're using nSRST reset for these targets.

  • 0 in reply to Edward Fewell
    Intellectual 460 points

    thank you so much for the detailed explanations!

    I'm indeed using the official 0.10.0 version of OpenOCD.

    I'll switch to TI tweaked version as suggested.

  • 0 in reply to Jose Simoes
    Intellectual 460 points

    I've managed to build the TI OpenOCD in Windows and I'm now using it.

    The initial error is gone but I now have this on the OpenOCD output:

    openocd: Info : JTAG tap: cc13x2.jrc tap/device found: 0x3bb4102f (mfg: 0x017 (Texas Instruments), part: 0xbb41, ver: 0x3)
    openocd: Info : JTAG tap: cc13x2.cpu enabled
    openocd: Error: Debug regions are unpowered, an unexpected reset might have happened
    openocd: Error: JTAG-DP STICKY ERROR
    openocd: Error: Could not find MEM-AP to control the core
    openocd: target halted due to debug-request, current mode: Thread
    openocd: xPSR: 0x61000000 pc: 0x1000118e msp: 0x11001ff0

    I have to say that I can run the debug fine, so not sure if it's completely safe to ignore those. Just wanted to check it with you.

    Thanks,