I’ve managed to make only couple of steps during program debugging – and then OpenOCD almost always crashes with Segmentation fault exception. Is older OpenOCD version more stable?

I have not tried using the latest version, but have found the version that I include in the FreeRTOS download to be very stable. I have however noted that the interface for hardware debugging in the latest Eclipse downloads has changed, which requires a bit of setup fiddling to get the projects to debug correctly.  Also the newer versions of OpenOCD have changed the command syntax, so they will not work with the scripts that are in the FreeRTOS download. Regards.

Hi Richard, as you said that a few things have changed, could you please sent an update for OpenOCD usage in new eclipse? And whatever else you can, if you find it may be usefull… :) Versions and setup for OpenOCD are very confising because it is allways changing… Is there a wiki somewhere that we can add our experiences and feeedback?

In OpenOCD source, there’s a lot ready files. The new schema was done to permit the creation of multiple configuration files, each one to specify a class of device, like one for jtag, another for each target and so on.

I think there is some king of misunderstanding. Please find below the summary of what I’ve understood. Please correct me If I am wrong. As I pointed in the first post in this topic, new (0.1.0) OpenOCD seems to be unstable. Then Richard concluded that the older OpenOCD version (I don’t know which version it is?) seems to be stable. Also he said that to make it working with new Eclipse you have to make some fiddling with OpenOCD configuration files included in FreeRTOS distribution. And finally I believe that alainm3 is after information how to fiddle these files. Richard, can you point me to the documentation for OpenOCD version, which is distributed with FreeRTOS? Best regards, Adam

I’m not sure of the command line option to get the version number, but openocd-pp (parallel port) is showing a build date of 2007-08-25 12:00 CEST, and open_ftdi is showing a build date of 2007-08-17 11:00 CEST. This might be the date that Richard built them though. They are in theDemoCommondriversOpenOCD directory.

Mostly I am interested in ftdi version, which I want to run with Turtelizer2 board and AT91SAM7X256. I am looking for documentation corresponding to this version/build of OpenOCD to avoid struggling with OpenOCD command syntax changing so rapidly. Thanks, Adam

Dear all, I’m currently working with OpenOD compiled from trunk 14xx and 16xx with support for Versaloon and FTDI based dongle (through FTD2XX). It is very stable and the MCU programming speed is increased. For sure this opinion is coming from my personal experience. I’m following some project based on STM32 MCU; the IDE is Eclipse Ganymede+CDT 5.0.2 and the one of the following dongle: Versaloon or JTAGKey-Tiny or Olimex. Regards, Stefano

Dear Stefano, Can you send me resulting executable files and configuration files on my email address: adas _at_ ikp _dot_ pl please ? I would like to try them on Windows platform and AT91SAM7X256 micro to check, if the stability will improve. Thanks, Adam

Stefano has send me executable of OpenOCD SVN 1690 version. It needs little configuration files fiddling (i.e. at91sam7 flash driver name has to be changed to at91sam7_new) and seems to be really more stable than 0.1.0. Once again thanks Stefano! Now I’ve got another problem ;-). gdb "step" instruction always tries to set software breakpoint, but as expected it fails on FLASH running MCU. thbreak command works. How to enforce that gdb will always set hardware assisted breakpoint (especially during "step" command)? Regards, Adam

I found the solution command "gdb_breakpoint_override hard" in OpenOCD configuration file does the job and converts all breakpoint set requests from gdb to be hardware assisted breakpoint. This of course limits the amount of available breakpoints to 2. I think it can be automaticaly changed to use software breakpoints if the code where we want to set breakpoint is running from RAM. It could be possible if gdb knows the memory layout – OpenOCD command "gdb_memory_map enable" looks promising. I am still trying to force GDB to read memory map. Any suggestions how to do that?