Difference between revisions of "Hardware/EIR/OpenOCD/NutOs"
(Created page with "<div id="content"> = OpenOCD for AT91SAM7SE - Part 9 = This is the last part of our OpenOCD for AT91SAM7SE tutorial. == Nut/OS Integration == OpenOCD can...")
Latest revision as of 11:06, 13 July 2017
OpenOCD for AT91SAM7SE - Part 9
This is the last part of our OpenOCD for AT91SAM7SE tutorial.
OpenOCD can be easily installed on Linux from the source code package. As this requires several Unix-like tools, which in turn rely on certain capabilities of the underlying OS, building OpenOCD on Windows is quite difficult and will most likely fail many times before you succeed, if ever.
For general use, I'd recommend Freddie Chopin's binary distribution for Windows, available at www.freddiechopin.info. If you want to use the EIR with Nut/OS, the Turtelizer support package is probably the better choice. The installation detects an existing Nut/OS installation, and places the OpenOCD executable into nut\tools\win32, which needs to be in your PATH environment anyway. Configuration scripts are stored in nut\tools\turtelizer2, for which Makefiles exist to allow using
make burn to build and upload your application binary in one go without hassle.
OpenOCD Command Line
Throughout this tutorial we simply started OpenOCD without any command line options. All required configuration was included in a local file openocd.cfg, either directly or by include external configuration files.
This will become inconvenient, if you are working on several different project, because each time you need to create a local openocd.cfg and over the time, some of them may become outdated when upgrading OpenOCD or Nut/OS and must be updated manually. If you stick to configurations files supplied by OpenOCD or Nut/OS, this can be avoided. Even if they won't fit, you only need to apply changes at one place to make all your projects work again.
Without a local configuration file, we need to tell OpenOCD, where to find them. This can be done in the same way as in our local configuration. More precisely, instead of reading commands from a file, you can provide commands on the command line, using the command line option
-c. Instead of using openocd.cfg with the follwoing lines
add_script_search_dir [../../nut/tools/turtelizer2] source [find interface/turtelizer2.cfg] source [find board/eir.cfg]
we can call OpenOCD with the following options.
openocd -s ../../nut/tools/turtelizer2 -c "source [find interface/turtelizer2.cfg]" -c "source [find board/eir.cfg]"
Nut/OS provides several Makefiles, which will automatically launch OpenOCD with the right command line options, when requested to build the
burn target. For example, entering
while in the directory of a sample application, configured for building applications running in external RAM, will build the binary image and finally call OpenOCD with the following options:
|-s ../../nut/tools/turtelizer2||Specifies the OpenOCD search path, which is located in the Nut/OS source tree.|
|-c "source [find interface/turtelizer2.cfg]"||Loads the JTAG programmer configuration, that had been selected by the programmer selection in the Nut/OS Configurator.|
|-c "source [find board/eir.cfg]"||Loads the board configuration of the EIR.|
|-c init||Switches OpenOCD from configuration stage to run stage.|
|-c "reset init"||Calls the reset init handler to initialize the hardware.|
|-c "load_image firmware.bin 0x20000000"||Transfers the firmware image to the SDRAM on the EIR.|
|-c "verify_image webradio.bin 0x20000000"||Verifies the firmware image with the contents of the SDRAM. This is optionally, but fast enough to allow this extra safety.|
|-c "resume 0x20000000"||Starts the uploaded firmware on the target.|
|-c shutdown||Shuts down OpenOCD, so the command line becomes available again for the next command.|
The result is, that your application starts running on your target with a snap. An even more interesting feature is, that if you configured Nut/OS be build applications that shall run in flash memory, the binaries will be programmed into flash instead. Magic, isn't it? How can this work?
When requested to build the target
burn, the Nut/OS Makefiles will figure out the Makeburn file with the configured extension. For OpenOCD, this is
nut/app/Makeburn.arm-oocd. Among other things, this file contains the following fragment:
ifeq ($(PLATFORM), ELEKTOR_IR1) BURNBOARD = eir # Initialize clocks and SDRAM. BURNCMDS += -c "reset init" ifeq ($(LDNAME), at91sam7se512_xram) # Load image into external SDRAM. BURNCMDS += -c "load_image $(ITARG) 0x20000000" # Verify image in external SDRAM. BURNCMDS += -c "verify_image $(ITARG) 0x20000000" # Start image in external SDRAM. BURNCMDS += -c "resume 0x20000000" endif ifeq ($(LDNAME), at91sam7se512_rom) BURNCMDS += -c "flash write_image erase $(ITARG) 0x100000 bin" BURNCMDS += -c "verify_image $(ITARG) 0x100000 bin" BURNCMDS += -c "at91sam7 gpnvm 2 set" BURNCMDS += -c "reset run" endif endif
This part is executed when building for the EIR, in which case PLATFORM is set to ELEKTOR_IR by the Nut/OS Configurator. Now the base name of the linker script is examined. If it has been configured as
at91sam7se512_xram BURNCMD will be loaded with the options we listed in the table above. If it's configured as
at91sam7se512_rom, then BURNCMD will be loaded with the command line options required to program the binary image into flash memory.
Not really. I'm sure there are many open questions and even bugs, as this is the first version. Watch out for updates.