Any time I want to use urjtag with Bus Blaster JTAG debugger V 2.5, I got the same error:
TDO seems to be stuck at 1
If I try with openocd, the problem is similar:
openocd -f /etc/openocd.cfg
Open On-Chip Debugger 0.7.0-dev-00066-gfc302a0 (2012-11-04-18:45)
Info : only one transport option; autoselect 'jtag'
adapter speed: 500 kHz
none trst_pulls_srst
Warning - assuming default core clock 12MHz! Flashing may fail if actual core clock is different.
trst_and_srst trst_pulls_srst srst_gates_jtag trst_push_pull srst_open_drain
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
adapter speed: 1500 kHz
Info : max TCK change to: 30000 kHz
Info : clock speed 1500 kHz
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: lpc2294.cpu: IR capture error; saw 0x0f not 0x01
Warn : Bypassing JTAG setup events due to errors
Info : Embedded ICE version 15
Error: unknown EmbeddedICE version (comms ctrl: 0xffffffff)
Info : lpc2294.cpu: hardware has 2 breakpoint/watchpoint units
Warn : ThumbEE -- incomplete support
Is it connected to the circuit during these errors? If so, I recommend a urjtag detect when it is not connected, that should give a stuck at 0 error which may help with narrowing things down.
Also if it is the first time you are using it, can you update the bitstream in the buffer? Maybe the test bitstream in there. This (http://http://code.google.com/p/dangerous-prototypes-open-hardware/downloads/detail?name=BusBlaster.package.v2.0.zip) package contains the buffer logic, and over here (http://http://dangerousprototypes.com/docs/Bus_Blaster_v2_buffer_logic#Programming) you can find the instructions for programming the onboard CPLD.
Thanks Tayken. Juan that is exactly what I would recommend too. If that fails the hardware could be defective. There is a self-test program we can try (windows only, I'm afraid, but source is available):
http://dangerousprototypes.com/docs/Bus ... e_selftest (http://dangerousprototypes.com/docs/Bus_Blaster_v2_manufacturing_resources#Hardware_selftest)
App and source are in the download here:
http://dangerousprototypes.com/docs/Bus ... #Downloads (http://dangerousprototypes.com/docs/Bus_Blaster#Downloads)
[quote author="ian"]There is a self-test program we can try (windows only, I'm afraid, but source is available):
http://dangerousprototypes.com/docs/Bus ... e_selftest (http://dangerousprototypes.com/docs/Bus_Blaster_v2_manufacturing_resources#Hardware_selftest)[/quote]
Wow! I totally forgot that it was Windows only. Well, nice thing is now I have a side project to work on. :)
Yes, I tryed with the jtag output disconnected, and I got the same error.
With openocd, when i sent a reset, with the output board connected, I got this error:
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: lpc2294.cpu: IR capture error; saw 0x0f not 0x01
Warn : Bypassing JTAG setup events due to errors
Warn : ThumbEE -- incomplete support
target state: halted
target halted in ThumbEE state due to watchpoint, current mode: System
cpsr: 0xffffffff pc: 0xfffffff9
Warn : NOTE! Severe performance degradation without fast memory access enabled. Type 'help fast'.
I found in the forum other similar case:
viewtopic.php?f=37&t=4023 (http://dangerousprototypes.com/forum/viewtopic.php?f=37&t=4023)
But in my case, the problem is that solder of the chip have too much tin, and make short circuit betwen the pins.
Thanks for Your help!
Thanks for the update, glad you got it going. I'm sorry about the bug too, I will ask Seeed to check over the current stock.
[quote author="Juan37"]But in my case, the problem is that solder of the chip have too much tin, and make short circuit betwen the pins.[/quote]
Nice catch Juan! You have the equipment to work on that, right? If not, just post on the forum.
No. I only have a ceramic pencil type solder. For this case, I must to have a hot air solder station, and it's very expensive in Argentina. I buyed the interface to de-brick a equipment.
Thanks
Not exactly, I don't have a hot air station but do little repairs with my soldering station. If you have a temperature controlled soldering station, you are fine. But if not, I can repair it and send it to you.
My ceramic pencil type welder, only has 2 levels of power, 22 watt and 150. It has about 25 years old. Now I see You are from Tokio. I mean you can get at a good price modern welders there!
You can help me on this issue? (to upgrade my welder)
Thanks
Please contact Seeed Studio and reference this thread, they will mail you a new board. You will not have to send the old one back, I already arranged it for you.
[quote author="Juan37"]My ceramic pencil type welder, only has 2 levels of power, 22 watt and 150. It has about 25 years old. Now I see You are from Tokio. I mean you can get at a good price modern welders there!
You can help me on this issue? (to upgrade my welder)
Thanks[/quote]
Well, I use a second hand Hakko 936 I bought from here, and Yen- USD conversion makes them more expensive actually. :) The problem is plug types and voltage levels are different. Why not check out eBay for a suitable one?
Hello, I have just received a brand new BusBlaster v3c from Seeedstudio.
I have been able to upload a jtagKey bistream into internal CPLD but I can't get it to work to program my external CPLD breakout board (the CoolRunner II).
Trying all that on Windows 7, I see 2 COM ports (and with his configuration the bistream got uploaded with no issues).
When runing UrJTAG (patched version), I get the following
-------------snip------------
jtag> cable JTAGkey
Connected to libftd2xx driver.
jtag> detect
discovery.c:117 urj_tap_detect_register_size() Warning: TDO seems to be stuck at
1
Error: parse.c:208 urj_parse_file() no error: Cannot open file 'C:UsersK/.jtag
/rc' to parse
-----------snip---------------
I tried the same with and without CPLD breakout connected (as suggested by one of the earlier posts here),
and in BOTH cases I get the TDO stuck at 1. (not 0 as expected with nothing connected).
Could that be the same issues with a shorted hardware ?
What should I do then ? contact Seeedstudio as well ?
** meanwhile I have uploaded bitstream again and made sure it's the bbv3.svf (to exclude any issues within the CPLD),
also tried to check continuity between pin 18 of FTDI and pin 14 of the CPLD - it's connected (along with the TDO pin on JP1) (but I did not verify any shorts yet).
Thanks.
Can you connect to the onboard CPLD and put the code here? Also can you reupload the bitstream and test?
I tried, and yes I can connect to the onboard CPLD (this is how I got the bistream there in the first place).
jtag> cable FT2232 interface=1
Connected to libftd2xx driver.
jtag> bsdl path c:/bsdl
jtag> detect
IR length: 8
Chain length: 1
Device Id: 00000110111000011100000010010011 (0x06E1C093)
Filename: c:/bsdl/xc2c32a_vq44.bsdl
jtag> svf c:/svf/bbv3.svf
jtag> svf c:/svf/bbv3.svf progress stop
Parsing 660/664 ( 99%)
Scanned device output matched expected TDO values.
jtag> quit
Just wanted to make sure everything was in order before going forward.
According to this (http://http://dangerousprototypes.com/docs/Bus_Blaster_v3_manufacturing_resources), the bitstream has test capability. You can download all the files from here: https://code.google.com/p/dangerous-pro ... urces/v3c/ (https://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/trunk/Bus_Blaster/manufacturing_resources/v3c/) Programming has all the files you have, Test has a special test program. Of course this comes with a warning.
hmm, now I'm puzzled, the self-test was successful:
C:UsersKDownloads>BusPiratev2Test_VisualC++Express.exe -delay -n0
Select device:
Device 0 (Serial Number: A
Device 1 (Serial Number: B
======================================================
SUCCESS (Connected to the FTDI.A)
SUCCESS (reset)
SUCCESS (usb parameters set)
SUCCESS (event chars disabled)
SUCCESS (timeouts set)
SUCCESS (latency set)
SUCCESS (flow control disabled)
SUCCESS (MSSPE reset)
SUCCESS (MPSSE on)
START TESTING
======================================================
00000001 00000001
00000010 00000010
00000100 00000100
00001000 00001000
00010000 00010000
00100000 00100000
01000000 01000000
10000000 10000000
00000000 00000000
10101010 10101010
01010101 01010101
00000000 00000000
11111111 11111111
Testing complete, errors: 0
C:UsersKDownloads>pause
Press any key to continue . . .
better yet, it seems to have finally started working...
I've ran a boundary scan, self-test, even hooked up a logic analyzer, uploaded the bitstream a couple times and now it works...
jtag> cable jtagkey
Connected to libftd2xx driver.
jtag> detect
IR length: 8
Chain length: 1
Device Id: 00000110111001011110000010010011 (0x06E5E093)
Manufacturer: Xilinx (0x093)
Part(0): XC2C64-VQ44 (0x6E5E)
Stepping: 0
Filename: c:program filesurjtagdata/xilinx/xc2c64a-vq44/xc2c64a-vq44
jtag>
(As a quick test I was able to read the status of the breakout board's push-button on CPLD pin 18 = IO_46 via boundary scan).
Interestingly, it doesn't play well with the Open Bench Logic Sniffer - both run on FTDI and things freeze when I have a capture armed and use urJTAG.
It does that. I don't use mine under Windows but I had similar problems under Linux. Uploading the bitstream couple of times solved it. Regular urJtag was good on Linux, I only had to provides vid and pid to it in order for it to connect. The reason they don't play well may be they both use FTDI but use different drivers: regular one is for serial port, other one is for bitbanging.
Yeah, I got it to work on my Mac as well after fighting with Apple's own FTDI driver and it looks like I'm set.
Thanks