Unreliable gdb-server load-run need manual reset-after-load

[rewolff]

to get the "load-run" to be reliable, I have a macro in gdb that does "reset - load - continue ".

When I use that on the ChibiOS stm32f072 demo app, it crashes "Unhandled exception". This seems to happen BEFORE main is being called: I can set a breakpoint at "main" but it stops in the unhandled exception before hitting the breakpoint.

The workaround seems to be to call "reset" after the load. My macro now does: "reset load reset continue". This works.

[xor-gate]

Is this not due to CPU directly running after reset and not properly halted. Verify if you see this with latest st-util from master.

[xor-gate]

Have you tested against v1.2.0 or master and if it still is a problem?

[rewolff]

First test of updated git version:

2016-05-21T09:52:31 WARN src/usb.c: Stlink usb device found, but unable to claim (probably already in use?)
[!] send_recv
2016-05-21T09:52:31 INFO src/gdbserver/gdb-server.c: Chip ID is 00000000, Core ID is  00000000.
[!] send_recv
2016-05-21T09:52:31 INFO src/gdbserver/gdb-server.c: Listening at *:4242...

How is this useful? No hardware, no chip, but serving GDB connections? (I don't understand how the 4242 bind can work, but the kernel returns "success" on the bind call).

P.S. Still working on testing the reset issue. Have to find a compiling source first.

[xor-gate]

Your last reported error is totaly unrelated which you reported jan 15, 2015. But you are right this is not very good. Please provide more details about your setup and if you have tested with st-info --probe and running as user or root. Device claiming is related to kernel/libusb.

• Programmer (or board)
• Target chip

[rewolff]

You're right. It's a different issue, but we both know about that, and you asked me to check the current solution where I had "hacked" a different solution for the "unable to claim" error.

Are you misunderstanding me? st-util is entirely correct when it says it cannot claim the USB interface. "probably already in use?" is 100% correct.

assurancetourix:~/stm32/stlink.git> sudo ./st-info --probe
Found 1 stlink programmers
 serial: 303030303030303030303031
openocd: "\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x31"
  flash: 131072 (pagesize: 2048)
   sram: 16384
 chipid: 0x0448
  descr: F07x device

st-info reports exactly the same when run as normal user than when run as root. No difference there.

P.S. Still working on testing the reset issue. Have to find a compiling source first.

[xor-gate]

I probably have misunderstand your actual problem. Currently the usb probe code (and error handling) is not as nice as it should be and needs a major refactoring. Your st-info probe is completely incorrect as the serial number of the stlink makes no sense probably you are using a newer programmer firmware (nucleo/discovery) which emits the serial number already encoded as hexstring. I already have a issue for this outstanding for milestone v2.0.0 here: #417. You should try to change this line to use 16 characters for the serial:
https://github.com/texane/stlink/blob/master/src/usb.c#L938

We need to refactor the code more and have way better error handling, which also needs a better log facility. Long story short, it needs some love here and there :+). And a simple hack will not resolve this problem.

[rewolff]

Ok. a bare reset-load-continue seems to work now. (in my limited testing).
On the other hand, the may-2015 version that I was using before also works with the application that I'm testing with now.
(I worked with "reset-load-continue" for a long time before I noticed that sometimes I needed the extra reset after the load).

As to the probe-issue..... I'm using an original stm32F3 discovery board as the stlink.

[Nightwalker-87]

Likely closed by #430 where an additional JTAG reset has been added prior to the call of stlink_reset.