Hi,
i've just received my Bus Blaster v2 this morning and I'm trying to get it work with Crossworks for ARM.
I've programmed the CPLD buffer as Amontec JTAGkey following these steps:
http://dangerousprototypes.com/docs/Bus ... ffer_logic (http://dangerousprototypes.com/docs/Bus_Blaster_v2_buffer_logic)
then i've modified the FTDI vid/pid with the Amontec ones (same vid, pid=cff8) to make Crossworks recognize it. It actually sees it, but it then fails reporting "Cannot set debug register".
Anyone had success with Crossworks? Did I missed some steps?
Update: as KT-LINK it seems to work very well, at leat 2x faster (from an user point of view: time to step into the code, time to update registers view etc) than the Olimex USB-TINY adapter I was using before. The only thing i had to do, as I'm working on OSX, was to modify the PID to something different from FTDI standards, in order to avoid to load the FTDI kext.
Anyway, it would be nice to discover how to get it work as JTAGkey too ;)
Hi tinito,
Thanks for testing the KT-LINK image, you are probably the first to try it :) Did you use it under Crossworks?
I'm not sure about the JTAGkey. Did you also set the USB descriptor to match the JTAGkey? I know some apps compare that too. JTAGkey may also have a target detect pin that we need to hold a certain way to satisfy Crossworks, I'm not sure though.
Hi Ian,
yes, I tested the KT-LINK image under Crossworks, and it works impressively well (and fast). Up to now I used it just "as usual", meaning flashing the firmware, executing it, setting breakpoints and looking at registers.
We have tested it also on a Linux host (I'm working on OSX) and it is recognized but fails during verify, there are some bytes (4-8 bytes, not more) that are systematically wrong (not a FLASH problem I think as our Olimex programmer is able to write the same firmware on the same MCU). We tried working with JTAG Clock Divider to slow down (forgive me ;) the programmer, but it fails exactly in the same way.
If I can help with some more test I will be really happy to do contribute!
About JTAGkey I modified vid, pid and descriptors too, and this enabled Crossworks to recognize the programmer (with FTDI standard vid/pid it was not enable to find it - not sure if the descriptor string was really necessary). But then it fails with "Cannot set debug register", maybe for the target detect pin you talked about. On Linux it behaves exactly the same. Do you have any suggestion? If there is some test I can arrange I'll be happy to contribute, again ;)
Just to summarize:
Crossworks, on OSX:
- KT-LINK working OK
- JTAGkey is recognized but then fails with "Cannot set debug register"
Crossworks, on Linux:
- KT-LINK seems to work OK, but it fails when verifying the uploaded firmware (4-8 wrong bytes, always at the same address)
- JTAGkey is recognized but then fails with "Cannot set debug register"
ps: i'm going on vacation for the next 5 days, but when i'll back i'll go on with the tests!
I can confirm that BBv2 works well with CrossWorks on OS X as a KT-link. BTW, you don't have to change the BBv2 PID or VID to use it with CrossWorks. You can use the context menu in the targets pane to copy and paste the existing KTLink entry to create a new copy. You can then change the name of the new copy and also change the PID/VID as appropriate to match the BBv2 (since PID/VID are properties of the KT-link target). I don't think you can do the same thing with the jtagKey entry since PID/VID don't seem to be parameters for that entry.
I was using BBv2 to program Cortex M3/M0 boards which needed SWD to program and debug. It all worked pretty well, with a very occasional communications hiccup. I don't know if that was the fault of the BBv2 or something else in my setup. Anyway, until OpenOCD gets support for SWD, it isn't easy to find any other way to program SWD boards except under Windows. I wish the license cost for even a personal edition of CrossWorks was less that $150. That is probably more than I want to spend just for Arm support.
@tinito - thanks for the extended bug report, it's really helpful. The first thing I want to do is convert all the buffers to Verilog (they are currently done with a schematic editor) and recompile. After that we can look at more specific issues. Do you know the memory addresses with the verify errors? Are they on logical boundaries or anything (256, 1024, etc?)
@sdixon - thanks for the report. If you have any more info on the glitches please share. These are the first real stress tests of BBv2 outside the lab, my CPLD logic may well have issues that can be fixed with an upgrade.
Sorry for the delay, I had some problems reconfiguring the bus blaster CPLD to go on with the tests. I tought it was a windows problem (it was not able to load the drivers, it took me some hours to get rid of this problem), but I'm still not able to program the CPLD.
UrJTAG warns about TDO stuck at 0, then the svf command fails. I have two bus blaster and both behave the same (i'm still using it on OSX, so i hope they are safe, i have problems only when trying to program the CPLD with UrJTAG).
jtag> bsdl path c:/bsdl
jtag> cable ft2232 interface=1
Connected to libftd2xx driver.
jtag> detect
Warning: TDO seems to be stuck at 0
jtag> svf c:/BBv2-KTlink-v1.0.svf progress stop
Error svf: chain without any parts
jtag> svf c:/svf/bbv2.svf progress stop
Any suggestion?
It has been awhile since I did it, but I think I reprogrammed the BBv2 on OS X using UrJTAG. I've not done it again recently since I found that the KT-link version worked pretty well for me for what I was doing. I'll go back a try it again and let you know if it works (or if I in fact reprogrammed the BBv2 some other way).
Hi tinito - I'm sorry about the upgrade issue.
Are you using your own compile of the latest urJTAG source? There were a few fixes for the Bus Blaster included recently. Maybe they caused problems or could help fix this problem.
Is it possible you have another ftdi device connected at the same time (Bus Pirate, Arduino, etc), urJtag attaches to the first device it finds.
Hi Ian, thanks for your reply: you were right, it works if I use latest svn version of urjtag. I'm able to program the CPLD, tomorrow I'll be in the lab to test it on Crossworks & linux, the platform i was not able to work with.
Thanks, it's great to have help testing on all the various platforms. I'll get the Verilog version of the buffer posted here tomorrow and maybe that will help some too.
This post has new verilog and vhdl versions of the buffer. Could you please test it and let me know if it helps:
viewtopic.php?f=37&t=2366&p=22512#p22512 (http://dangerousprototypes.com/forum/viewtopic.php?f=37&t=2366&p=22512#p22512)
Ok, today we've made some more tests with Crossworks:
- KTLINK on Linux: he verify fails always at the same addresses, but they are not "notable" addresses. The errors are in the same place also when flashing a different firmware.
- new VHDL/Verilog (tried both) JTAGKEY firmware: the same behavior as the old ones. It says "Cannot write debug register" on both Linux and OSX.
Now the interesting news: if we program the CPLD to emulate the JTAGKEY buffer and in Crossworks we configure it as KTLINK....... it works! we tried step by step execution and breakpoints, and all works well. It also writes at speeds of 2Mbit/s, much more than our old Olimex programmer.
Pretty strange, isn't it? ;)
Uh, i've just found this (sorry for looking for that so late):
http://rowley.zendesk.com/entries/40323 ... g-register (http://rowley.zendesk.com/entries/403236-cannot-set-debug-register)
So it seems a problem of JTAGKEY, not of the BusBlaster. I've tried those settings on OSX and it works fine, it should work also on Linux. Do we have to put that configuration on the wiki?
To summarize:
- JTAGKEY works fine with "conservative" parameters (Adaptive clocking: No, JTAG Clock Divider: 2, nSRST/nTRST Open Drain: Yes)
- KTLINK works on OSX but fails the verify on Linux. It strangely works with the CPLD flashed as JTAGKEY and Crossworks configured to work with KTLINK....
Thanks for your great support!
Thanks for the additional testing, feedback, and research. It is a big relief to know the hardware isn't causing this issue. I added an issues section to each buffer:
http://dangerousprototypes.com/docs/Bus ... gic#Issues (http://dangerousprototypes.com/docs/Bus_Blaster_v2_buffer_logic#Issues)
I'm still curious about the KTLINK fail under Crossworks/Linux. I believe there was a tester who used it successfully with OpenOCD under Linux (?).