TI CC3220 debugging fails

Sysprogs forums Forums VisualGDB TI CC3220 debugging fails

This topic contains 4 replies, has 2 voices, and was last updated by  hoterpone 1 month, 2 weeks ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
  • #33759


    For several years we have been using VisualGDB to debug our code running on embedded Texas Instruments CC3220SF chips.  We connect from the PC via USB to a CC3220SF-LAUNCHXL board, which includes an onboard XDS110 JTAG emulator that we bridge to our CC3220 CPU.

    In the last few months we have been using VisualGDB to debug ESP32-S2 chips, and in the course of that have upgraded VisualGDB and the OpenOCD packages to the latest.  But this week I needed to investigate something on the CC3220SF, and now I’m unable to debug — every time I try to start debugging I get a message “Could not write to register ‘msp'”.  I’ve tried multiple boards with the same result, and even had a colleague try with his own laptop and hardware setup, and now he’s getting the same error as well.

    At this point we’ve run out of ideas of things that we might have done wrong ourselves, and so I started wondering if perhaps something has changed in the VisualGDB environment.  So I wanted to ask if you guys have tried debugging a CC3220SF with the latest versions of VisualGDB and/or OpenOCD or if you’re aware of any issues.

    Attached is a screenshot showing the existing installed VisualGDB packages.  I am running VisualGDB v5.6R9 build 4777.





    You must be logged in to view attached files.



    Most likely, you have updated the OpenOCD package to the latest version, and it might contain a bug that would be interfering with the CC3220 debugging.

    The easiest way to revert it is to try installing an older OpenOCD build as shown on this page.

    If it solves the problem, please let us know the exact OpenOCD versions that work and don’t, and also the exact error output you are getting from OpenOCD, and we will look further into it to see if we can fix it on our side.



    Thanks — yes after reverting forwards and backwards a couple times it appears that this worked in the previous OpenOCD version 20211118-0.11.0 but now fails with the latest OpenOCD version 20230111-0.12.0.  I did not try any of the OpenOCD versions that appear to be forks for specific microcontrollers e.g. ST Fork or STM8 since I assume those wouldn’t apply for the CC3220/CC3235, but let me know if you’d like me to try any of those.

    The attached ‘msp Error.png’ shows the initial popup message that I see when trying to debug.  Following is a copy of the full gdb stub log:

    C:\Users\xyz\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\bin\openocd.exe -c “gdb_port 65485” -c “telnet_port 65483” -f interface/xds110.cfg -c “adapter speed 2500” -c “transport select jtag” -f target/ti_cc3220sf.cfg -c init -c “reset init” -c “echo VisualGDB_OpenOCD_Ready”
    Open On-Chip Debugger 0.12.0 (2023-01-11) [https://github.com/sysprogs/openocd]
    Licensed under GNU GPL v2
    libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3
    For bug reports, read
    adapter speed: 2500 kHz

    Info : XDS110: connected
    Info : XDS110: vid/pid = 0451/bef3
    Info : XDS110: firmware version =
    Info : XDS110: hardware version = 0x0027
    Info : XDS110: connected to target via JTAG
    Info : XDS110: TCK set to 2500 kHz
    Info : clock speed 2500 kHz
    Info : JTAG tap: cc32xx.jrc tap/device found: 0x0b97c02f (mfg: 0x017 (Texas Instruments), part: 0xb97c, ver: 0x0)
    Info : JTAG tap: cc32xx.cpu enabled
    Info : [cc32xx.cpu] Cortex-M4 r0p1 processor detected
    Info : [cc32xx.cpu] target has 6 breakpoints, 4 watchpoints
    Info : starting gdb server for cc32xx.cpu on 65485
    Info : Listening on port 65485 for gdb connections
    Info : [cc32xx.cpu] requesting target halt and executing a soft reset
    Error: Could not write to register ‘msp’

    Info : XDS110: disconnected


    You must be logged in to view attached files.


    OK, we have investigated it further and thankfully it was a trivial bug that we were able to fix.

    Turns out, the logic behind the soft_reset_halt command got changed at some point so that it wasn’t waiting for the target to actually halt. We have updated the CC3220SF script to explicitly wait for the halt and it appears to be working now. Feel free to install the latest OpenOCD package via Tools->VisualGDB->Manage VisualGDB Packages.




    I downloaded the OpenOCD update (20230202-0.12.0) and this appears to be working again — thanks!

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.