Using Openocd As A Standalone Flash Programmer: Motivation
Using Openocd As A Standalone Flash Programmer: Motivation
Programmer
(a simple tutorial)
Motivation
Using OpenOCD as just a programmer instead of a debug tool is very convenient in cases of mass production where
you already have a prebuilt and already debugged image and you only need to download that image to the target device.
In this mode of operation programming becomes as easy as starting the OpenOCD executable – all the rest is automatic.
To implement the programming function of OpenOCD you need to add some lines to the configuration file of the target.
These include commands to program the target and commands to start the programming itself.
After locating the correct configuration script for your target you need to create a procedure inside in the file to be
called to program the device. This procedure will contain the operations for programming. If, for example, it is called
“program_device” the syntax will go like this:
proc program_device () {
<commands>
…
}
Note: Please follow the exact syntax, i.e. the needed space between the name of the procedure and the empty brackets.
Luckily enough, all these operations are contained in the “flash write_image”, so provided with the correct parameters
it may be the only command inside the body of the procedure. Please consult OpenOCD User’s Guide to see how this
command works. However, additional commands may be needed or desired to accompany the “flash write_image”.
Here is a sample procedure for programming AT91SAM7S256.
proc program_device () {
# halt the processor
halt
wait_halt
#exit OpenOCD
shutdown
}
In this case “flash write_image” is used to its full potential to erase and unlock flash memory before writing the image.
Note that you should also provide the image file to program as well as the start address of the flash memory in the
device. The example uses a binary file, however there are other formats supported. Besides, the input image file is
located in the directory of OpenOCD, otherwise a relative of absolute path will be required. The target device is reset
and run after programming. At the end of this procedure OpenOCD shuts down.
Note: The procedure you create should be put somewhere in the configuration file, there is no exact place for it.
The next thing to do is to put commands to actually start the programming process. Locate the end of the configuration
file and add these lines (the place of the commands here is actually important!):
init
reset init
program_device ()
Please again note the space between the procedure name and the brackets.
General note: It is actually not a bad idea to initially test basic connectivity with the device prior to editing the
configuration file.
Starting OpenOCD
The OpenOCD executable file is called: openocd-libftdi.exe. It is ready to run and needs no installation!
If you do not provide any file with the –f switch the default file to search for is 'openocd.cnf' so do not get upset if you
just start 'openocd-libftdi.exe' and end up with an error message. If you are using ARM-OCD-H and an
AT91SAM7S256 processor, for example, type:
> openocd-libftdi.exe -f olimex-arm-usb-ocd-h.cfg -f sam7s256.cfg
This command line assumes that both configuration files and the image file reside in the same folder as the OpenOCD
executable. Upon starting OpenOCD connects to the JTAG module of the target device and reset is executed. Then the
programming starts (successful execution is marked with an arrow) and after that the target is run.
Note: OpenOCD is quite verbose by nature. Although most of the warnings it provides are meaningful and worth
clearing, the process will finish just fine in most cases in spite of the warnings.
Conclusion
Please note that OpenOCD is sometimes pretty tricky to work with so be aware of configuration and runtime issues.
Well, if things get very ugly you should stop the server, reconnect the JTAG adapter and start over.
Revision history
− 31 January 2011 – initial release.
THE END