Skip to content

psherman42/Demystifying-OpenOCD

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

14 Commits
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Demystifying-OpenOCD

or, Smallest Toolchain in the World

How often does OpenOCD seem to crash or mis-perform for no apparent reason? Do you feel like you're back to trial-and-error mode?

Here are a bunch of overrides for the start-up process, proper delays, handling of those ever so common (and annoying) failures during scan and examine. Also included are a couple suggestions for high level loading procedures for ram and rom destinations.

These tips will give a very useful, brief, and highly readable log of all progress steps that OpenOCD goes through -- and you can see at exactly which step those Messages, Warnings, and Errors from from!

The linker script .lds file can be revised for ram or rom targets in the .text and .rodata sections; or, a separate script can be made for each and selected in turn by different makefiles or makefile command line arguments or options.

Then in the makefile, for example, fe310.mk, you would have a pair of link instructions where the last line (indented with tab, of course) invokes the openocd program -- which I presume is already specified in your system path.

So that at the command line, to do a full build (compile, assemble, link, load, and target device erase, program, and verify) the smallest toolchain in the world is easy:

make -f fe310.mk rom
or
make -f fe310.mk ram

The line of the makefile which does the actual loading of compiled, assembled, and linked code is

openocd -f fe310-g002.cfg -c "adapter speed 2000" -c init -c "asic_rom_load my_prog"\

-c shutdown -c exit

where my_prog-rom.bin has been linked for rom target addresses in the linker .lds script.

About

Some helpful config file TCL tips

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published