13:53 <kraator> Hi, I recently updated OpenOCD (supplied by Zephyr SDK) from 0.11.0+dev-00244-g7e3dbbbe2 (2021-11-18-07:14) to 0.11.0+dev-00724-g42b6471c1 (2022-08-17-18:23) and now I can't flash my TI3235SF via SWD any more. OpenOCD scripts have minimal changes in openocd/scripts/target/ti_cc3220sf.cfg, (which also gets used for the cc3235sf), but these don't

13:53 <kraator> seem to cause the issue.

13:54 <kraator> the older version prints:

13:54 <kraator> Open On-Chip Debugger 0.11.0+dev-00244-g7e3dbbbe2 (2021-11-18-07:14)

13:54 <kraator> Licensed under GNU GPL v2

13:54 <kraator> For bug reports, read

13:54 <kraator>         http://openocd.org/doc/doxygen/bugs.html

13:54 <kraator> ocd_process_reset_inner

13:54 <kraator> Info : XDS110: connected

13:54 <kraator> Info : XDS110: vid/pid = 0451/bef3

13:54 <kraator> Info : XDS110: firmware version = 3.0.0.18

13:54 <kraator> Info : XDS110: hardware version = 0x0027

13:54 <kraator> Info : XDS110: connected to target via SWD

13:54 <kraator> Info : XDS110: SWCLK set to 2500 kHz

13:54 <kraator> Info : clock speed 8500 kHz

13:54 <kraator> Info : SWD DPIDR 0x2ba01477

13:54 <kraator> Info : cc32xx.cpu: hardware has 6 breakpoints, 4 watchpoints

13:54 <kraator> Info : starting gdb server for cc32xx.cpu on 3333

13:54 <kraator> Info : Listening on port 3333 for gdb connections

13:54 <kraator>     TargetName         Type       Endian TapName            State

13:55 <kraator> For bug reports, read

13:55 <kraator>         http://openocd.org/doc/doxygen/bugs.html

13:55 <kraator> ocd_process_reset_inner

13:55 <kraator> Info : XDS110: connected

13:55 <kraator> Info : XDS110: vid/pid = 0451/bef3

13:55 <kraator> Info : XDS110: firmware version = 3.0.0.18

13:55 <kraator> Info : XDS110: hardware version = 0x0027

13:55 <kraator> Info : XDS110: connected to target via SWD

13:55 <kraator> Info : XDS110: SWCLK set to 2500 kHz

13:55 <kraator> Info : clock speed 8500 kHz

13:55 <kraator> Info : SWD DPIDR 0x2ba01477

13:55 <kraator> Info : [cc32xx.cpu] Cortex-M4 r0p1 processor detected

13:55 <kraator> Info : [cc32xx.cpu] target has 6 breakpoints, 4 watchpoints

13:55 <kraator> Info : starting gdb server for cc32xx.cpu on 3333

13:55 <kraator> Info : Listening on port 3333 for gdb connections

13:55 <kraator>     TargetName         Type       Endian TapName            State

13:55 <kraator> --  ------------------ ---------- ------ ------------------ ------------

13:55 <kraator>  0* cc32xx.cpu         cortex_m   little cc32xx.cpu         halted

13:58 <PaulFertser> kraator: please never paste more than 2-3 lines to a public IRC channel, use some pastebin instead.

13:58 <kraator> sorry, I'm not used to IRC

13:59 <PaulFertser> kraator: please pastebin somewhere what new version prints

13:59 <PaulFertser> I can't see any real errors mentioned

13:59 <PaulFertser> Probably start with openocd -d2 to get more essential debug info about what's happening under the hood.

14:07 <kraator> -d2 doesn't add any new info about why it is failing. The new version prints https://pastebin.com/27CPuUPC, while the old one looks like this: https://pastebin.com/KKkk9xJK

14:09 <PaulFertser> kraator: and please stay on channel, someone will get back to you

14:10 <kraator> ok thanks

14:27 <kraator> -d3 actually adds some info about an internal error code while trying to write the msp register: https://pastebin.com/R8wcFjhK

15:40 <PaulFertser> kraator: yes, not being able to write to msp would break the reset sequence as it's currently defined.

15:40 <PaulFertser> kraator: what does "reg" command print? Probably msp name changed?

15:41 <PaulFertser> Doesn't look like it...

15:43 <PaulFertser> kraator: try adding "halt" after soft_reset_halt

15:43 <PaulFertser> -304 means ERROR_TARGET_NOT_HALTED

15:44 <PaulFertser> soft_reset_halt is really rarely needed so must be some regression after refactoring but additional "halt" should remedy it.

16:53 <kraator> Adding halt after soft_reset_halt in openocd/scripts/target/ti_cc3220sf.cfg indeed fixed the issue! Thanks!

16:55 <PaulFertser> kraator: can you probably create a ticket on sourceforge so that it would be fixed upstream one way or the other?

16:56 <kraator> sure

16:56 <PaulFertser> Thank you

17:15 <borneoa_> kraator: if I remember correctly, the openocd in zephyr os has one patch to avoid a double reset... an issue that hit TI ccXXXX devices because makes ness in their jtag. Maybe you can check in zephyr openocd repo and cherry pick that patch. It should also be in our openocd gerrit and not approved. I cannot find more info at the moment, sorry.

18:28 <PaulFertser> borneoa_: it seems like somehow soft_reset_halt is not setting some internal OpenOCD target variable to signal it's in the halted state.

18:39 <borneoa_> PaulFertser: it should be done by the polling. I will have a look...

18:41 <PaulFertser> borneoa_: thank you!