Semihosting unusable due to excesive verbosity #82
Comments
See e.g. #39 for some of the "fun" involved... |
|
I'm not surprised, maintaining an old fork is generally a big pain in the rear, both for the maintainers and for the users. The faster the specific content is contributed upstream, the better for everybody. |
|
Default branch is now 0.12.0 |
|
The verbosity is no longer a problem, but with the openocd built from the default branch, exactly the same application as used in the initial report (the blinky with some semihosting writes) no longer runs: ilg@berry:~/pico/pico-examples/build/blink $ openocd -f interface/cmsis-dap.cfg -c "adapter speed 5000" -f target/rp2040.cfg -c "program blink.elf verify" -c "arm semihosting enable" -c "arm semihosting_cmdline test one two" -c "reset"
Open On-Chip Debugger 0.12.0-g97d1e6e (2023-07-07-22:47)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 5000 kHz
Info : Hardware thread awareness created
Info : Hardware thread awareness created
Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E6616407E339502C
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: Test domain timer supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 5000 kHz
Info : SWD DPIDR 0x0bc12477, DLPIDR 0x00000001
Info : SWD DPIDR 0x0bc12477, DLPIDR 0x10000001
Info : [rp2040.core0] Cortex-M0+ r0p1 processor detected
Info : [rp2040.core0] target has 4 breakpoints, 2 watchpoints
Info : [rp2040.core1] Cortex-M0+ r0p1 processor detected
Info : [rp2040.core1] target has 4 breakpoints, 2 watchpoints
Info : starting gdb server for rp2040.core0 on 3333
Info : Listening on port 3333 for gdb connections
[rp2040.core0] halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00
[rp2040.core1] halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00
** Programming Started **
Info : Found flash device 'win w25q16jv' (ID 0x001540ef)
Info : RP2040 B0 Flash Probe: 2097152 bytes @0x10000000, in 32 sectors
Info : Padding image section 1 at 0x10002474 with 140 bytes (bank write end alignment)
Warn : Adding extra erase range, 0x10002500 .. 0x1000ffff
** Programming Finished **
** Verify Started **
** Verified OK **
semihosting is enabled
semihosting command line is [test one two]
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Error: [rp2040.core1] target not halted
Warn : resume of a SMP target failed, trying to resume current one
Error: [rp2040.core0] resume failed
Error: Failed to resume target
Polling target rp2040.core0 failed, trying to reexamine
Info : [rp2040.core0] Cortex-M0+ r0p1 processor detected
Info : [rp2040.core0] target has 4 breakpoints, 2 watchpoints
[rp2040.core0] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x10000394 msp: 0x20041fb8, semihosting
[rp2040.core1] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00
And, BTW, the default branch in the repo might be $ git clone https://github.com/raspberrypi/openocd.git --branch rp2040 --recursive --depth=1 |
|
Please advice on how to proceed, since the current openocd is no longer functional. |
|
Do you get the same result with the upstream development branch? Clone this repository and do the same test. https://github.com/openocd-org/openocd |
The behaviour seems to be the same, i.e. it hangs: Pretty bad from my point of view, since I was about to make a new binary release based on the latest upstream, but if this will break my tests, that's bad... :-( I think that you should not only keep your fork up-to-date, but also keep the upstream functional for the Pico. |
|
I can't replicate your failure with downstream or upstream versions. Upstream for reference: And I get a blinking LED. |
Ah, sorry, I used the blink project as a starting point, now it is not blinking but exercising some semihosting calls. Please replace the files in the sdk with the following: The source code is a bit weird, it was copied from another project and patched, because I knew that the original was functional.
I don't know, it is the one provided by the openocd distribution, I did not change it. |
|
The problem is that your code contains a breakpoint instruction, and I can also get successful execution if I disable SMP support by adding |
I'm not sure I understand where the problem is. My code uses the breakpoint instruction to invoke the semihosting API. How do you suggest to run a semihosted application without issuing a reset after flash programming?
It might be so, but the point is to run unit tests as standalone semihosted applications, i.e. without GDB and manual interventions. OpenOCD should be able to do this (I know this because several years ago I re-wrote the entire semihosting code in OpenOCD, I guess it is still functional).
For my current unit tests I don't need the second core, but for future tests I expected it to be available. Can you summarise the current situation and suggest a solution or at least a workaround if things are not yet clear? |
|
From more verbose debug, it looks like the swi breakpoint isn't being handled by openocd correctly. I would recommend disabling SMP as per above. I'm not sure why an unrelated configuration change apparently stops semihosting from working. |
|
This is being discussed upstream - https://sourceforge.net/p/openocd/mailman/openocd-devel/thread/D91BB62E-C8A4-433B-90BF-BE6D1D3EC22B%40livius.net/#msg37868743 |
|
Yes, I know, I opened that thread. :-) But I'm not sure it is the same issue. I'll try to clarify that first and return to this one later. |
I edited the blink example to write some semihosting messages, but a
target halted due to debug-request...message is displayed with each semihosting command, making the output unreadable:With a newer openocd (0.12.0), the output for the same elf is:
I don't know the reason why you still recommend in the documentation to use such an old openocd, but, for semihosted applications, the excessive verbosity makes it unusable.
The text was updated successfully, but these errors were encountered: