OpenOCD is a popular open source JTAG utility. Zach Welch, a regular contributor to the project, has offered to help add Bus Pirate support. You can follow the progress in his git repository.
The current plan is to port the excellent work done by the USBPROG project to the Bus Pirate. Here are some tentative goals:
* Port the AVR/USB-based microcontroller code from USBPROG to the Bus Pirate. Modify the code to work through the PIC serial port.
* Add a Bus Pirate device to OpenOCD based on the existing USBPROG source code. Modify the code to write and read through a serial port.
* Add message header, checksum to the existing USBPROG protocol.
I'm wondering if this solution is functional enough to use or it will be a while?
We have been using the Amontec JTag with OpenOCD for Arm software development but one has died. Even though they work I'm reluctant to buy a replacement since they provide no support and have a shipping policy that would see them in court if they operated here.
So now I'm looking at open source JTag solutions first. I like the idea of the Bus Pirate but looking here it appears it may not be quite ready for general use. Is there another path that I should be following now and give this option time to mature, or is it worth jumping in and taking a punt?
So far there has been no beta testers. But I have been using the Buspirate as OpenOCD interface for a while, and i have had no problems so far.
It is not the fastest interface out there, but it works :)
Debuging is realtime-ish - in the first version i had to wait few seconds for one gdb step, now it takes <1 second. (tested with STM32 cpu)
I would be happy if you could give it a try !
i'd be happy to test, but i have no idea how to get started. Is there a "dummies guide for dummies" on OpenOCD/JTAG, say for someone who has an ATMEGA32 sitting around and with zero JTAG experience to start with (ie will still need help or pointers to fuse level info)? Yes, I am a mega dummy with a ATMEGA32 :)
OpenOCDs primary target is ARM. I'm not sure if there is any atmega support.
According to openocd-devel mailing list
http://lists.berlios.de/pipermail/openo ... 05734.html (http://lists.berlios.de/pipermail/openocd-development/2009-April/005734.html)
There is support for the avr cpu. They have tested mega128 succesfully. I guess that for mega32 you would need to change few numbers (IDs)
i guess I was hoping for a *real* "dummies" guide. My eyes glazed over in the first few seconds of reading that article :) Guess I'm not going to be any use in the test cycle sorry
Robots,
i'm trying to get a couple of hours to test the openOCD/Buspirate integration but unfortunately i'm quite busy right now.
But i'd like to say kudos for your impressive work and programming skills. Well done man!!!
I have created patch for the latest git repo. I have also sent it to the development mailing list, so that it should be easier for others to use this interface :)
Hi robots,
i was going to ask you for a patch of openOCD last revision (0.4.0). Can you also post it in the bus pirate repositories?
Thank you,
robots,
I just checked out and built the openocd repository. Also just got my bus pirate. So I am ready to do some testing whenever you need it!
Latest patch that applies to the git repository is attached. I have emailed it to the devel mailing list for review. It should apply without any major problem. Then you will need to enable the buspirate interface compilation using:
./configure --enable-buspirate --enable-maintainer-mode
(maintainer mode is needed when compiling development version)
Some short howto on how to use openocd is on my blog. It points out some things you need to configure before using openocd (maybe gdb) and the target.
http://michaldemin.wordpress.com/2010/0 ... d-openocd/ (http://michaldemin.wordpress.com/2010/02/22/part-2-debugging-with-gdb-and-openocd/)
When testing, just be sure that your target JTAG is 3v3 compatible :)
Current state is "works-for-me", and I don't think that many bugs will emerge.
>When testing, just be sure that your target JTAG is 3v3 compatible :)
Can you use other target voltages If you turn pullup resistors on, and supply Vextern with
the JTAG interface voltage? This is a real issue for FPGAs and CPLDs.
Sure you can, just be sure to edit the buspirate.cfg config file. You want to set it to something like:
buspirate_mode open-drain
buspirate_pullup 1
Edit: I'll post detailed tutorial tomorrow.
simple "how to" buspirate and openocd:
http://michaldemin.wordpress.com/2010/0 ... d-openocd/ (http://michaldemin.wordpress.com/2010/02/27/how-to-buspirate-and-openocd/)
Hi robots,
i followed the steps you post in the howto. But some problems have arose:
-When i updated buspirate firmware with the one you provided, does it replace bootloader (v4.2) somehow? the GUI only allowed me to burn the new firmware if the bootloader can be overwritten.
-Related to previous one... is there any way to check if the buspirate has the openocd firmware up and running via terminal?
Thank you,
The firmware does not replace bootloader. I did use the pirate-loader because the GUI didn't work for me.
The OpenOCD support is binary only. I guess you need to send 20 times 0x00. It should reply with "BBIO1" and afterwards you sent 0x06 it should reply "OCD1". Not all terminal programs can send arbitrary hex values. I was using Realterm.
Hi robots,
finaly, i'd managed to update my buspirate firmware and build the openOCD (0.5.0-dev-00066-g17d437a-dirty). I've sucessfully connected to a STM32F106 CPU. But when i tried to make a flash dump to test the transfer speed ( dump_image /home/slimfish/backup.bin 134217728 131072) i've got the following error:
Open On-Chip Debugger 0.5.0-dev-00066-g17d437a-dirty (2010-03-10-09:39)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html (http://openocd.berlios.de/doc/doxygen/bugs.html)
srst_only separate srst_gates_jtag srst_open_drain
1000 kHz
jtag_nsrst_delay: 100
jtag_ntrst_delay: 100
Info : Buspirate Interface ready!
Error: Translation from jtag_speed to khz not implemented
Info : interface specific clock speed value 1000
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'telnet' connection from 0
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000120 msp: 0x20000a7c
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0x80000004
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0x80000004
Warn : Block read error address 0x80000000, count 0x8c
Command handler execution failed
Do you know what does the error mean? (i'm pretty new to OpenOCD). By the way, i'm not using TRST pin... could be that the source of the error?
Congratulations robots (as i'm afraid that the error is not in the code but in my openocd 'skills'). Again, kudos to you.
NEWS: Patch has been merged into git master branch. :)
slimfish:
How long is the cable from BP to the target board ?
I am getting the same error with my new board. There seems to be some kind of interference. I have also been getting the same error with wiggler adapter when my cable was about 30-40 cm long.
There is a option in the FW to slow down, but it has not been implemented in OpenOCD yet.
Fantastic, congratulations!
The cables are quite short, about 10cm or less and all run in parallel. If you had the same problem with the wiggler and long cables maybe firmware is toggling JTAG lines too fast.
Tomorrow i'll try to make the cable shorter (3cm) and test again.
I'll report as soon as i get something useful.
I wonder if it is not something with the chip.
Because I have STM32-103STK olimex dev board (the board i have developed the bp openocd firmware with), the cable is ~15cm long, and I do not get any errors with full speed flashing and/or debugging.
I've compared schematic of Olimex dev. board with the board i have (DSO Nano) and JTAG resistors are not exactly the same (18K instead of 10K) and not all resistors are pull-up. So i will try to match the resistors in your board and see what happens... but unfortunately that will be on monday.
Yesterday I got my new BPv3 in the post, straight away upgraded to FW 4.2, built OpenOCD from git, wired BP with my STM32 board and got it all running on the first try! Thanks Michal for your awesome work.
One little problem though: When OpenOCD is killed with Ctrl-C it leaves BP in 1MHz binmode (?) and on subsequent run fails to run with "Error: Buspirate did not respond : ( restart everything" and BP has to be restarted.
IMO in such a case OpenOCD should attempt to reset it - switch to binmode and eventualy fastmode and try a reset. Eventually use a a signal handler to catch Ctrl-C and reset BP before exiting.
i think that signal handler could not be added to the Git repo, it is platform specific, and openocd is able to compile on windows, linux, and some embedded cpus.
If you shutdown openocd by using the "shutdown" command from the telnet console, it cleans up properly. I am aware of this bug, and i will fix it as soon as i get some nice idea :)
The "nice idea" can be borrowed from my avrdude approach to the very same problem - under normal circumstances avrdude resets from binmode upon exit, just like openocd does. If it dies unexpectedly it leaves BP in binmode, probably in SPI mode in the middle of data transfer. Again similar to OpenOCD.
When avrdude detects upon startup that BP isn't responding it calls buspirate_reset_from_binmode(), that's normally called in the exit path, and then retries initialisation. IMO OpenOCD should do the same. Perhaps first with the speed set in config file (fast or normal) and if it still wouldn't work retry once again with the other speed (ie normal or fast respectively), just in case the config has changed since the last run.
I dont like the idea of sending bunch of data (worst case 2-3k) to a random device at different speeds.
In the case of init problems it's IMO much more likely that BP was left in a wrong state than that the device is not a BusPirate. However I agree that blindly sending data to a device may not be a good idea.
On the other hand my BP appears as /dev/ttyBusPirate - the chances of something else appearing under this name are zero and I would be comfortable with OpenOCD reseting the BP for me whenever it encounters problems. How about implementing a config file directive "buspirate_auto_reset on/off" or a command line switch --buspirate-reset or -c "buspirate_reset" or something along those lines? And advise accordingly what to do in the "blah blah reset everything" message.
Until the "/dev/ttyBP" thing is in official udev, or at least adopted by some major distro, i do not consider it standard :)
I agree that "Restart everything" message it not really good, but i was aiming for the functionality. I will add more "states" to the state machine to be able to print more descriptive message.
I was thinking about using RTS or CTS line to reset the OpenOCD interface. It should by enough to reset the uart speed setting back to 115k and quit ongoing transfer (if any). The existing code can deal with that.
ToDo right now looks like this (order is relevant):
- implement speed setting in OpenOCD
- implement interrupt handling for CTS or RTS line to reset OpenOCD bin mode in FW.
- add reseting procedure to the OpenOCD
- fix bugs
- fix more bugs
- add support for WIN32
slimfish:
I seem to have solution for the weird behavior. I have read the OpenOCD mailing list, and there seems to be bug/feature of some kind. If you run the openocd like this:
openocd -f openocd.cfg -c "init" -c "halt" -c "reset halt"
The problem goes away! Halt command puts the CPU into halt state, preventing the error from happening, after that issuing the "reset halt" command "fixes" the error somehow.
Robots:
thank you, i'll check it as soon as i can and then i will report the obtained read/write speeds.
Thank you