Issues using newest version of OpenOCD (0.10.0)

[Ancaritha]

I recently updated my openOCD to the latest release of 0.10.0 to get support for the new STM32L49 series of processors.  When I did this I am no longer able to debug/program things through Visual Studios that are using an STM32L071 processor.  If I go to Visual GDB properties -> Debug Settings -> Test  OpenOCD settings, it works fine.

The error message is:

Error: jtag status contains invalid mode value – communication failure
Info : Previous state query failed, trying to reconnect
Error: error writing to flash at address 0x08000000 at offset 0x00000000

GDB then spits out the error: Error finishing flash operation

 

If this occurs (around a 90% chance) then new code is not loaded and I can’t debug it.

 

I have also tested with a L152, L053 and L496 and didn’t have any issues.  Since I can revert to OpenOCD to 0.9.0 and everything works, I’m 99% sure that this is an OpenOCD bug.  However, I was curious if anyone else experienced this same issue?  I was using VisualGDB 5.1r6 but updated to 5.2r9 when I first started having issues; there was no difference between the two.

 

In relation to this, would there be anyway to download previous version of packages using VisualGDB ‘Manage Packages’.  Right now you can only update to the newest version, it’d be nice if you could get previous version of OpenOCD.  Some things appear to support it but most do not.

[support]

Hi,

The ” jtag status contains invalid mode value” usually indicates a wiring problem and could be a result of a damaged board (or the new OpenOCD might be using a higher SWD frequency).

Either way, you can download the older versions of OpenOCD package here:

• http://sysprogs.com/files/visualgdb/hwsupport/EDP/com.sysprogs.arm.openocd/openocd-20161025.vgdbxedp
• http://sysprogs.com/files/visualgdb/hwsupport/EDP/com.sysprogs.arm.openocd/openocd-20161014.vgdbxedp
• http://sysprogs.com/files/visualgdb/hwsupport/EDP/com.sysprogs.arm.openocd/openocd090r11.vgdbxedp

 

[Ancaritha]

Just wanted to post a quick update in case anyone else was having this issue.  I finally got an eval board of an L073 and that has the same issue as my board, so it’s definitely an OpenOCD problem.  I checked the two print outs and the clock speed didn’t change but the expected flash size did change from 128Kb to 96Kb, so it may have to do that.

[support]

Hi,

Thanks for confirming this. As a quick check, could you please try replacing the OpenOCD executable (not the entire package, e.g. scripts) with the older version and confirm that this fixes the problem? If yes, please try adding “-d3” to the OpenOCD arguments to enable verbose debug logging and try comparing the logs for the old and the new executable. They might explain the differences between the behavior of the 2 versions. If you could attach both logs here, we might be able to tell what has changed and find a way to fix it.

[Ancaritha]

I originally tried changing just the exe and that did not resolve the issue, so I believe it has to be with the underlying scripts (or at least, it’s not just the exe’s fault).  I will turn on the verbose debugging and take logs when I get a chance.  Hopefully that’ll be later today but I’m not sure if I’ll get the chance.

[support]

Hi,

If the problem is related to the scripts, it should be much easier to pinpoint (sorry, we don’t have STM32L071 on our side to reproduce this). Simply run OpenOCD with the -d3 flag, get a list of involved scripts (or manually check the ‘find’ statements) and try replacing half of the involved scripts at a time to see if this affects the behavior. This should help locate the script responsible for the problem in just a few iterations.

[Author]

Posts