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?