I am using Eclipse/gcc/OpenOCD/GDB. If I set a break point and run the program it correctly stops at the breakpoint. However, if I then try to run from it the program remains stuck at the breakpoint. I have to single-step beyond the breakpoint, then I can run. This doesn't happen all the time, but when it does I can't find a way round it. Any ideas?
You need a newer version of openocd - this has been fixed. Cheers Spen
Spen Thanks for the response. I am currently using openocd v0.5.0. What is the latest version, and how can I download it? Regards Alan
The support for skipping breakpoints was added just before the 0.4 release - so you should already have it. I would need to see openocd and gdb logs to be able to comment further. Cheers Spen
Spen I have been struggling on, but it is getting to be more of a problem. I would like to send the openocd and gdb logs if you could then identify the problem. However, where do I find them? I am using Codesourcery GPPlite, which I believe includes openocd and gdb. I can't find anything that looks like a these log files in either the Codesourcery folder or the Eclipse workspace. Regards Alan
Codesourcery will include gdb but not openocd. Where did you get openocd from? To enable logging in openocd either pass the following on the cmd line openocd -d3 -l openocd.log ... or add to your openocd config debug_level 3 log_output openocd.log Also let me know what config and cmd line you are using for openocd. To enable logging in gdb add the following to your gdb init file set remotelogfile gdb.log Cheers Spen
Spen Thanks for your offer of help. I have attached a zip file containing openocd.cfg, openocd.log and gdb.log. I have also attached the .ini file used by GDB and a screenshot showing the code stopped at a breakpoint. I am running openocd-0.5.0-dev-100617191010.exe. This was supplied by a sub-contractor who has been helping on this project, so I don't know its origins. I tried to resume from the breakpoint twice. On both occasions the debug window briefly changed to highlight 'Embedded GDB', then reverted to the state shown. I then clicked Step Over and the code advanced to line 82 as expected. I could then Resume and the code ran correctly. I would be very grateful for any suggestions you can offer. Regards Alan
I think a lot has todo with the way you are masking interrupts. With the stm cortex you can enable a global method (cortex_m3 maskisr on|off) or use the DBGMCU_CR register. You are using the gdb hooks and the maskisr cmd. The only issue i see is you seem to have a typo in your hookpost-step macro - is the 'off' missing? Other than that the only other route is to provide a testcase. Cheers Spen
Thanks for your suggestions. You spotted the problem - my openocd .ini file had got corrupted so 'mon cortex_m3 maskisr off' was corrupted to 'mon cortex_m3 mask'. Correcting this fixed the problem. Incidentally, it took me a long while to come up with the solution of using gdb hooks to allow the project to be debugged. Hooks are briefly described in the 'Debugging with GDB' manual, but not in enough detail to allow ayone without good knowledge of GDB to use them. Someone gave me the details through a forum. The DBGMCU_CR register within the ARM architecture only allows timers to be disabled while debugging. My project uses USARTs that can be receiving data at all times, and these can't be masked through the DBGMCU_CR register. Without the gdb hooks the systems was constantly in USART interrupt routines when trying to single step. Thanks again for your help
Before sending my last response I thought the problem was fixed by correcting the typo in the .ini file. However, it isn't. I followed through the suggestion that the problem was caused by the hooks in .ini. I have tried deleting all of them, and the project still won't continue from a breakpoint. (Without the hooks, if I step from a breakpoint the code goes into an interrupt handler and won't exit from it because RTC, USB and UART interrupts are continuously being generated). I don't know how I can produce a testcase because the set-up involves a lot of code, a jTag interface and our target. How much of this would be needed to simulate the problem?