SpooniSpoon
commented
2 years ago Hi, I have the same issue. Any idee so far to solve the issue?
Closed omicronns closed 1 year ago
SpooniSpoon
commented
2 years ago Hi, I have the same issue. Any idee so far to solve the issue?
omicronns
commented
2 years ago I'm using gdb load command to flash the board. Using zephyr hello-world binary I can flash the board multiple times, with RIOT I can only do it once, and then I get an error. It seems to be related with binary content somehow.
I'm using same gdb script for both:
target remote localhost:3333
loadAnd command lines:
openocd -f board/ti_cc13x2_launchpad.cfgthen:
arm-none-eabi-gdb bin/cc1352-launchpad/hello-world.elf -x gdb.scriptor
arm-none-eabi-gdb build/zephyr/zephyr.elf -x gdb.scriptIt looks like running RIOT binary breaks JTAG connection somehow until I erase the flash with uniflash.
I tried to flash now using telnet connection with openocd, which seems more low-level. I can flash RIOT binary multiple times using commands:
reset init
flash write_image erase bin/cc1352-launchpad/hello-world.elfBut after I run the binary with reset run I can't flash the board anymore using previous commands, I'm getting following openocd output now:
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
cortex_m reset_config vectreset
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : XDS110: connected
Info : XDS110: vid/pid = 0451/bef3
Info : XDS110: firmware version = 3.0.0.19
Info : XDS110: hardware version = 0x0023
Info : XDS110: connected to target via JTAG
Info : XDS110: TCK set to 2500 kHz
Info : clock speed 5500 kHz
Info : JTAG tap: cc13x2.jrc tap/device found: 0x3bb4102f (mfg: 0x017 (Texas Instruments), part: 0xbb41, ver: 0x3)
Info : JTAG tap: cc13x2.cpu enabled
Info : cc13x2.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for cc13x2.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'telnet' connection on tcp/4444
Info : JTAG tap: cc13x2.jrc tap/device found: 0x3bb4102f (mfg: 0x017 (Texas Instruments), part: 0xbb41, ver: 0x3)
Info : JTAG tap: cc13x2.cpu enabled
Warn : Only resetting the Cortex-M core, use a reset-init event handler to reset any peripherals or configure hardware srst support.
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000930 msp: 0x20000200
Error: Invalid ACK (0) in DAP response
Error: Invalid ACK (0) in DAP response
Error: Failed to write memory and, additionally, failed to find out where
Error: Invalid ACK (0) in DAP response
Error: Invalid ACK (0) in DAP response
Warn : target was in unknown state when halt was requested
Error: Invalid ACK (0) in DAP response
Error: Invalid ACK (0) in DAP response
Error: failed erasing sectors 0 to 1
auto erase enabled
Error: Invalid ACK (0) in DAP response
Polling target cc13x2.cpu failed, trying to reexamine
Error: Invalid ACK (0) in DAP response
Error: Invalid ACK (0) in DAP response
Error: Invalid ACK (0) in DAP response
Error: Invalid ACK (0) in DAP response
Error: Invalid ACK (0) in DAP response
...I can flash multiple times running it in between using both telnet and gdb with zephyr image.
maribu
commented
1 year ago With https://github.com/RIOT-OS/RIOT/pull/19050 it should already be possible to flash again with OpenOCD (when using the release candidate or a recent build from OpenOCD's master branch) ... most of the time. I hope I can fix the reset halt so that it doesn't bring the JTAG interface in defunct state but works reliable, as just halt may cause issues if the board already installed IRQ handlers that trigger during flashing... But at least for me it worked 100% of the time anyway with the current state, so this may be better than resorting to uniflash.
Regarding the issue with the reset button on the nRF5x: Try flashing the app in dist/tools/nrf52_resetpin_cfg. The reset pin can be disabled in the persistent MCU config (I don't recall the correct name for it - it was called eFuses in AVR terminology). In case of the nRF5x I am 100% certain that this is not an issue with RIOT, but just some board come out of factory with the reset pin not activated. (And also the nRF5x is known to occasionally wipe the persistent config by accident during flashing. This is particularly annoying as it sets the logic level to 1.8 V by default, and only few debuggers have logic level converts included that are needed to restore the config.)
It may be that the CC13xx / CC26xx also have the reset pin configurable similar to the nRF5x. If so, it would be quite feasible to provide a similar tool to restore the reset config - or maybe even just an OpenOCD script.
Hi,
I'm playing with RIOT, and I'm experiencing strange behavior after flashing RIOT binary onto LAUNCHXL-CC1352R1.
After flashing hello-world example I can't connect via openocd (JTAG) with the board anymore. I can recover using uniflash tool from TI to erase the flash. Also physical reset button present on the board stops working - board continues to run despite button being pressed.
Is this expected behavior? Does RIOT-OS reconfigure JTAG and reset button in runtime so it is no longer operational?
Reset button behavior is also present for the nRF52840-DK development board.
Flashing the board for the first time:
After first flash: