#48 Problem repeating debug sessions on ARM STM32 platform
Hello,
I am using gnuarmeclipse under Ubuntu, debugging on a Custom platform embedding a STM32F105 chipset.
I am debugging using olimex-arm-usb-tiny-h Jtag.
I followed the installation provided by Liviu and I must say this works pretty well to start with.
However I encounter annoying problems when trying to repetitively stop and start debugging sessions.
To terminate a debug session, I click on "Terminate".
I have to power-up my board again to restart, and it usually happens that I am unable to restart the debugger because of getting following message :
Error in final launch sequence
Failed to execute MI command:
-target-select remote localhost:3333
Error message from debugger back end:
localhost:3333: Connection timed out.
localhost:3333: Connection timed out.
At the end, I usually have to restart my laptop.
Even after disconnecting the jtag and powering-up my device, I am unable to recover the debug, and this is frustrating to have to restart my laptop every 15mn...
I am looking for openocd commands that I could launch on the terminal to recover this but unfortunately, this does not seem to work.
Would you please have an advice on how to solve this ?
Thanks,
Ludo
this message comes from the gdb client, not able to connect to the openocd gdb server.
check if after Terminate the openocd is still there. if so, try to kill it manually.
this seems quite a radical solution.
I suggest you disable starting openocd automatically, and experiment with starting it manually. if you still have problems, there must be something wrong with openocd or with the configuration you are using.
frankly, neither openocd nor the olimex tiny are not professional solutions.
Hello Liviu,
thank you for your reply.
After Terminate, openocd is not there anymore.
I just tried to make the manual start of openocd, once I am blocked, and it seems to work.
I believe this because it somehow takes time to connect the board for openocd, ans since eclipse starts gdb in the same time, there is a timer elapsing.
I understand the comment about openocd and olimex, but I am part of a very tiny company, and this is very important for me to minimize costs as much as possible.
This is working not so bad until now ... :)
Thank you very much for your feedback,
Ludo
let me check if I got it right: probably due to the very low speed jtag, openocd takes quite some time to start, and since Eclipse starts the gdb client immediately after openocd, it might try to connect to an openocd not ready to accept connections. is this what you are saying?
as far as I know, the plug-in has a 30 seconds timeout, so if gdb does not connect in 30 seconds, the session will be aborted. but I'm still not able to find an explanation for the behaviour you are reporting...
if you further diagnose the problem and have some suggestions on how to improve the plug-in, please let me know.
regarding olimex tiny, I don't know how much you paid for it, but the list price is 40 EUR, while a J-Link EDU is only a few EUR more. the price/quality ratio for tiny makes it very expensive for what it does.
Liviu,
sorry for not coming back sooner.
Yes this is the behavior I have. I need to further characterize the duration after which it fails.
Once I launch manually openocd from a terminal, I open GDB from Eclipse afterwards and it works fine.
My view is that you need to ensure that gdb server launched by openocd is up and running before launching GDB client. And it seems openocd launches the server only when the connection with the device is done.
I will try to come back on this as soon as possible to give how much time it takes to connect to the device in the failing case.
Thanks
And I will follow your recommendation next time I buy a jtag device ... :)