24 replies to this topic

[jes1111]

Total newb on these things. I've read and followed everything I can...

- I get the JTAG showing up in Device Manager as "USB Serial Converter A" and "USB Serial Converter B" - with FTDI drivers
- I'm on Win7 64, so using OpenOCD 0.5 for x64 - appears to be correctly installed and happy
- JTAG is Rev B, so my arguments in Eclipse to start the daemon are:

-f ${workspace_loc}/flight/Project/OpenOCD/foss-jtag.revb.cfg -f ${workspace_loc}/flight/Project/OpenOCD/stm32f1x.cfg -c init

But I can't get the daemon to run - I get:

Open On-Chip Debugger 0.5.0 (2011-08-09-23:26)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berli...xygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
Error: unable to open ftdi device: device not found
in procedure 'init'

Help!

[D-Lite]

jes1111, on 06 December 2011 - 10:46 AM, said:

Total newb on these things. I've read and followed everything I can...

- I get the JTAG showing up in Device Manager as "USB Serial Converter A" and "USB Serial Converter B" - with FTDI drivers
- I'm on Win7 64, so using OpenOCD 0.5 for x64 - appears to be correctly installed and happy
- JTAG is Rev B, so my arguments in Eclipse to start the daemon are:

-f ${workspace_loc}/flight/Project/OpenOCD/foss-jtag.revb.cfg -f ${workspace_loc}/flight/Project/OpenOCD/stm32f1x.cfg -c init

But I can't get the daemon to run - I get:

Open On-Chip Debugger 0.5.0 (2011-08-09-23:26)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berli...xygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
Error: unable to open ftdi device: device not found
in procedure 'init'

Help!

Your setup looks very similiar to mine except that I have "${workspace_loc:/OpenPilot_Master/flight/Project/OpenOCD}" set as a working directory and then use "-f foss-jtag.revb.cfg -f stm32f1x.cfg -c init".. in the Arguments section. But the result should be the same. You could try to add a debug level, "-d 1" for example to see more debug output and also could try to run openocd from the command line. Another thing to verify is if the PID/VID specified in the foss-jtag.revb.cfg file matches the information you see for your JTAG device in the Windows system device manager.
But I'm on WinXP/32bit so there may be other issues with Win7/64bit.

[jes1111]

Thanks for your tips. Upping the debug level gives a clue:

Debug: 211 88 ft2232.c:2469 ft2232_init(): ft2232 interface using shortest path jtag state transitions
Debug: 212 88 ft2232.c:2342 ft2232_init_libftdi(): 'ft2232' interface using libftdi with 'usbjtag' layout (0403:6010)
Error: 213 90 ft2232.c:2364 ft2232_init_libftdi(): unable to open ftdi device: device not found
Debug: 214 91 command.c:638 run_command(): Command failed with error code -100
User : 215 91 command.c:679 command_run_line(): in procedure 'init'

So it appears to be trying to use libftdi drivers but the legit FTDI drivers (installed already for other hardware) have grabbed it already - does that make sense? How can I get past this? Is there a way to force OpenOCD to use the FTDI drivers?

PID/VID in Device Manager appear to match .cfg file (0x0403 and 0x6010).

[D-Lite]

jes1111, on 06 December 2011 - 12:44 PM, said:

So it appears to be trying to use libftdi drivers but the legit FTDI drivers (installed already for other hardware) have grabbed it already - does that make sense? How can I get past this? Is there a way to force OpenOCD to use the FTDI drivers?

Looks different on my machine:

Debug: 212 313 ft2232.c:2157 ft2232_init_ftd2xx(): 'ft2232' interface using FTD2XX with 'usbjtag' layout (0403:6010)

I think it's a compile time option which library to use. Did you install the "official" OpenOCD binary? I use a version osnwt compiled some time ago for native ft2232 support, but I don't know if it's available for download somewhere.

[jes1111]

  A little progress... maybe...

I uninstalled the FTDI proprietary drivers and installed the open ones. In Device Manager I now see:

 Capture ftdi.PNG   14.68K   6 downloads

No idea why I get the warning under "Other devices".

Back in Eclipse when I try to start the daemon, I get:

Open On-Chip Debugger 0.5.0 (2011-08-09-23:26)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
Info : clock speed 1000 kHz
Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: stm32.cpu: IR capture error; saw 0x00 not 0x01
Warn : Bypassing JTAG setup events due to errors
Warn : Invalid ACK 0 in JTAG-DP transaction
Polling target failed, GDB will be halted. Polling again in 100ms
Polling target failed, GDB will be halted. Polling again in 300ms
Polling target failed, GDB will be halted. Polling again in 700ms
Polling target failed, GDB will be halted. Polling again in 1500ms
Polling target failed, GDB will be halted. Polling again in 3100ms
Polling target failed, GDB will be halted. Polling again in 6300ms
Polling target failed, GDB will be halted. Polling again in 6300ms
........etc.......

UPDATE: I get the same by running from a bash command line. Also, it's the same whether the CC board is plugged to the JTAG or not. My "feeling" is that my software ducks are now all in a line, that there's some hardware issue here. I soldered the JTAG header onto this board myself, so I just reflowed the connections but no change. I get the power LED on the JTAG, and the usual blue/green on the CC.

[jes1111]

Another update: I don't like the header arrangement (my soldering including) - so I removed the header from the CC board and hardwired the necessary lines between the pads on the CC board and the legs of the header socket on the JTAG.

New result:

Open On-Chip Debugger 0.5.0 (2011-08-09-23:26)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
Info : clock speed 1000 kHz
Info : JTAG tap: stm32.cpu tap/device found: 0x0000006f (mfg: 0x037, part: 0x0000, ver: 0x0)
Warn : JTAG tap: stm32.cpu	   UNEXPECTED: 0x0000006f (mfg: 0x037, part: 0x0000, ver: 0x0)
Error: JTAG tap: stm32.cpu  expected 1 of 1: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : TAP stm32.bs does not have IDCODE
Warn : JTAG tap: stm32.bs	   UNEXPECTED: 0x00000000 (mfg: 0x000, part: 0x0000, ver: 0x0)
Error: JTAG tap: stm32.bs  expected 1 of 7: 0x06412041 (mfg: 0x020, part: 0x6412, ver: 0x0)
Error: JTAG tap: stm32.bs  expected 2 of 7: 0x06410041 (mfg: 0x020, part: 0x6410, ver: 0x0)
Error: JTAG tap: stm32.bs  expected 3 of 7: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
Error: JTAG tap: stm32.bs  expected 4 of 7: 0x06420041 (mfg: 0x020, part: 0x6420, ver: 0x0)
Error: JTAG tap: stm32.bs  expected 5 of 7: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
Error: JTAG tap: stm32.bs  expected 6 of 7: 0x06418041 (mfg: 0x020, part: 0x6418, ver: 0x0)
Error: JTAG tap: stm32.bs  expected 7 of 7: 0x06430041 (mfg: 0x020, part: 0x6430, ver: 0x0)
Warn : Unexpected idcode after end of chain: 33 0x00000000
Warn : Unexpected idcode after end of chain: 65 0x000001b0
Warn : Unexpected idcode after end of chain: 97 0x00000000
Warn : Unexpected idcode after end of chain: 129 0x00000000
Warn : Unexpected idcode after end of chain: 161 0x00000080
Warn : Unexpected idcode after end of chain: 193 0x03fdf1fc
Warn : Unexpected idcode after end of chain: 225 0x007f7efc
Warn : Unexpected idcode after end of chain: 257 0x0000007e
Warn : Unexpected idcode after end of chain: 289 0x00000000
Warn : Unexpected idcode after end of chain: 321 0x00000000
Warn : Unexpected idcode after end of chain: 353 0x00003fc0
Warn : Unexpected idcode after end of chain: 385 0x00000000
Warn : Unexpected idcode after end of chain: 417 0x00000000
Warn : Unexpected idcode after end of chain: 449 0xfbf7f1fc
Warn : Unexpected idcode after end of chain: 481 0x00000001
Warn : Unexpected idcode after end of chain: 513 0x01fdf7e0
Warn : Unexpected idcode after end of chain: 545 0x00000000
Warn : Unexpected idcode after end of chain: 577 0x00000000
Error: double-check your JTAG setup (interface, speed, missing TAPs, ...)
Error: Trying to use configured scan chain anyway...
Error: stm32.cpu: IR capture error; saw 0x03 not 0x01
Warn : Bypassing JTAG setup events due to errors
Warn : Invalid ACK 0 in JTAG-DP transaction
Polling target failed, GDB will be halted. Polling again in 100ms
Polling target failed, GDB will be halted. Polling again in 300ms
Polling target failed, GDB will be halted. Polling again in 700ms
...etc...

Any ideas, anyone?

[jes1111]

Hmmm... hardwired connections not a good idea (according to James) - so I've put the header back on. The result is still the same, though. But, interestingly, the values it finds (and proclaims as "UNEXPECTED") are not the same now. I presume it's querying the target to verify what it is, but it seems to be getting a muddled answer.

[PT_Dreamer]

jes1111, on 06 December 2011 - 09:30 PM, said:

Hmmm... hardwired connections not a good idea (according to James) - so I've put the header back on. The result is still the same, though. But, interestingly, the values it finds (and proclaims as "UNEXPECTED") are not the same now. I presume it's querying the target to verify what it is, but it seems to be getting a muddled answer.

This may sound crazy but I have problems with certain USB cables, so maybe try using another. Also you are powering the board right?
If the above doesn't work I would try using the FTDI drivers and use the OpenOCD version compiled against the FTDI libs.

[jes1111]

Okay, I'll try some different cables.

What do you mean by "powering the board right"? I'm connecting USB to both JTAG and CC - I've tried either order and it doesn't seem to make any difference.

I looked into OpenOCD with the FTDI drivers, but the only guide I could find for how to compile that was for a Ubuntu machine (even though it was targeted at Windows) - and I don't have such (or know anything at all about it).

[jes1111]

UPDATE: I've tried every USB cable I've got, in every USB port I've got (front of case and back of case). I also discovered that I can run the libusb-win32 installer twice and install both USB devices, so now they are listed (as "JTAG" and "JTAG 2") in Device Manager and I no longer have an "Other devices" section showing a warning.

Nevertheless - I still get the same problem.

This "muddled response" seems to align with the statement on this page that:

Quote

...at the time of writing OpenPilot is incompatible with OpenOCD 0.5.0 (although check the forums for news). OpenOCD sends too many registers to GDB, making GDB ignore most if not all commands.

EDIT: no, that doesn't make sense, does it? I haven't got as far as running GDB yet!

This has been a very demoralising two days trying to get this JTAG to work. Writing the module (that I now want to debug) was a "walk in the park" compared to the effort of setting up the dev/build environment in the first place and now fighting the JTAG!

[peabody124]

I would definitely try using the driver and openocd others have been successful with.

[PT_Dreamer]

jes1111, on 06 December 2011 - 10:37 PM, said:

UPDATE: I've tried every USB cable I've got, in every USB port I've got (front of case and back of case). I also discovered that I can run the libusb-win32 installer twice and install both USB devices, so now they are listed (as "JTAG" and "JTAG 2") in Device Manager and I no longer have an "Other devices" section showing a warning.

Nevertheless - I still get the same problem.

This "muddled response" seems to align with the statement on this page that:



This has been a very demoralising two days trying to get this JTAG to work. Writing the module (that I now want to debug) was a "walk in the park" compared to the effort of setting up the dev/build environment in the first place and now fighting the JTAG!

I have sent you the OpenOCD compiled for the FTDI drivers, Oleg compiled that some time ago but I don't think it can be posted here.

[jes1111]

You're a star, but....

I believe I've now switched it back to using the proper FTDI drivers, but I still get the same behaviour:

Open On-Chip Debugger 0.5.0 (2011-09-13-20:49)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
Info : device: 4 "2232C"
Info : deviceID: 67330064
Info : SerialNumber: A
Info : Description: Dual RS232 A
Info : clock speed 1000 kHz
Info : JTAG tap: stm32.cpu tap/device found: 0x00000477 (mfg: 0x23b, part: 0x0000, ver: 0x0)
Warn : JTAG tap: stm32.cpu	   UNEXPECTED: 0x00000477 (mfg: 0x23b, part: 0x0000, ver: 0x0)
Error: JTAG tap: stm32.cpu  expected 1 of 1: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : TAP stm32.bs does not have IDCODE
Warn : JTAG tap: stm32.bs	   UNEXPECTED: 0x00000000 (mfg: 0x000, part: 0x0000, ver: 0x0)
Error: JTAG tap: stm32.bs  expected 1 of 7: 0x06412041 (mfg: 0x020, part: 0x6412, ver: 0x0)
Error: JTAG tap: stm32.bs  expected 2 of 7: 0x06410041 (mfg: 0x020, part: 0x6410, ver: 0x0)
Error: JTAG tap: stm32.bs  expected 3 of 7: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
Error: JTAG tap: stm32.bs  expected 4 of 7: 0x06420041 (mfg: 0x020, part: 0x6420, ver: 0x0)
Error: JTAG tap: stm32.bs  expected 5 of 7: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
Error: JTAG tap: stm32.bs  expected 6 of 7: 0x06418041 (mfg: 0x020, part: 0x6418, ver: 0x0)
Error: JTAG tap: stm32.bs  expected 7 of 7: 0x06430041 (mfg: 0x020, part: 0x6430, ver: 0x0)
Warn : Unexpected idcode after end of chain: 33 0x00413ba0
Warn : Unexpected idcode after end of chain: 65 0x0ff16410
Warn : Unexpected idcode after end of chain: 97 0x000007f0
Warn : Unexpected idcode after end of chain: 129 0x00000000
Warn : Unexpected idcode after end of chain: 161 0x00000000
Warn : Unexpected idcode after end of chain: 193 0x000001fc
Warn : Unexpected idcode after end of chain: 225 0x00000000
Warn : Unexpected idcode after end of chain: 257 0x00000000
Warn : Unexpected idcode after end of chain: 289 0x00003fc0
Warn : Unexpected idcode after end of chain: 321 0x01fbf7f0
Warn : Unexpected idcode after end of chain: 353 0x001fbf7e
Warn : Unexpected idcode after end of chain: 385 0x00003f80
Warn : Unexpected idcode after end of chain: 417 0x00000000
Warn : Unexpected idcode after end of chain: 449 0x00000000
Warn : Unexpected idcode after end of chain: 481 0x00000ff0
Warn : Unexpected idcode after end of chain: 513 0x00000000
Warn : Unexpected idcode after end of chain: 545 0x00003f80
Warn : Unexpected idcode after end of chain: 577 0x0fdfbf80
Error: double-check your JTAG setup (interface, speed, missing TAPs, ...)
Error: Trying to use configured scan chain anyway...
Warn : Bypassing JTAG setup events due to errors
Warn : Invalid ACK 0 in JTAG-DP transaction
Polling target failed, GDB will be halted. Polling again in 100ms
Polling target failed, GDB will be halted. Polling again in 300ms
Polling target failed, GDB will be halted. Polling again in 700ms
Polling target failed, GDB will be halted. Polling again in 1500ms
Polling target failed, GDB will be halted. Polling again in 3100ms

[jes1111]

Okay - many thanks to D-Lite, James and José for assistance so far.

Decision time! Do I...

- assume there's a problem with the JTAG and try to replace it? (Is there some way to fully verify functionality of the JTAG?)
- keep going as I am, on the assumption that I've missed some tiny detail that would be obvious to you clever chaps?
- assume that W7x64 is the root of the problem and move this effort to a 32-bit machine? (not convenient)
- assume that Windows is the problem and build myself an Ubuntu (?) machine just for flight firmware dev? (not keen on this one!)
- give up and throw my rattle out of the pram? (not my style, although I'm close!)
- look for another alternative?

-

[peabody124]

The easiest thing if you do mind losing a few days would be post it to Jose (check me out volunteering him) and that will verify the hardware.  Splitting the problem in half will save you some headache.

[D-Lite]

PT_Dreamer, on 06 December 2011 - 11:05 PM, said:

I have sent you the OpenOCD compiled for the FTDI drivers, Oleg compiled that some time ago but I don't think it can be posted here.

That's the version I also use, but the 32bit version of it.

jes1111, on 07 December 2011 - 01:39 AM, said:

- assume there's a problem with the JTAG and try to replace it? (Is there some way to fully verify functionality of the JTAG?)
- keep going as I am, on the assumption that I've missed some tiny detail that would be obvious to you clever chaps?
- assume that W7x64 is the root of the problem and move this effort to a 32-bit machine? (not convenient)

From the last bunch of messages you posted, I would assume the communication to the interface is okay and there's something wrong on the JTAG level. I remember having messages like this with my "usbprog" JTAG interface when I had wrong connections. If you soldered the header to CC, then replaced it with wires and then reinstalled the header again, maybe there's a small shortcut, bad solder joint or something like this? I'm shure you already checked this, but that's one of the few things that comes to my mind.  Another cause could be a "wrong" stm32f1x.cfg file but if you use the one from flight/Project/OpenOCD and didn't change anything in that file, it should be okay.
Unfortunately, I dont's see a way to directly verify that the FOSS is 100% working. The USB part works for shure but if the JTAG side of the device is working also is hard to tell without a scope. So trying it in an environment that is know to work is certainly the  easiest way to test this out.
Regarding the 32/64bit problem - would be good to know if someone here successfully uses OpenOCD on Win7/64. If you do, please raise a hand . As far as I know, Oleg build that 64bit version but couldn't test if it works.

[jes1111]

To clarify, José sent me the 32-bit version of OpenOCD/FTDI - it seems to run quite happily on my W7x64 (i.e. no messages/warnings). I would be surprised if a "real" x64/FTDI version did now solve my problem, since the symptoms shown with 32-bit/FTDI are the same as with x64/libUSB version. I'm certainly willing to try, though, if somebody can send it to me.

Regarding my soldering, during the course of fitting/removing/hardwiring/removing/refitting, I've certainly had a few shorts, but corrected them. I've also messed up the pads quite a bit, but currently no detectable shorts. Maybe having those short-circuits messed up the JTAG. Maybe inserting it backwards (in a desperate attempt to see any result) messed it up.  If you've ever tried it you'll know - the header solders on quite easily, but removing it is a b@@@@!

[D-Lite]

jes1111, on 06 December 2011 - 11:49 PM, said:

Info : JTAG tap: stm32.cpu tap/device found: 0x00000477 (mfg: 0x23b, part: 0x0000, ver: 0x0)
Warn : JTAG tap: stm32.cpu	   UNEXPECTED: 0x00000477 (mfg: 0x23b, part: 0x0000, ver: 0x0)
Error: JTAG tap: stm32.cpu  expected 1 of 1: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)

This part is interesting - it actually does get something back via JTAG, the "0477" part of the device ID is correct, only the first two byte (0x3ba0) are missing. This somehow smells like a 32/64bit problem but that's just guessing. But with bad hardware, I wouldn't expect to see this 0477 value showing up here.

[dankers]

Are you on 64 bit windows? If yes you need 64 bit drivers. Using FTDI Compiled OpenOCD? The you need 64bit FTDI drivers, 100%

Bad hardware: very very unlikely, I did the design for this version and it is very very simple, the FOSS JTAGs were also assembled at one of the best fab houses around and cost me a lot of $$.

[D-Lite]

dankers, on 07 December 2011 - 09:30 PM, said:

Bad hardware: very very unlikely,

jes1111, on 07 December 2011 - 09:36 AM, said:

Regarding my soldering, during the course of fitting/removing/hardwiring/removing/refitting, I've certainly had a few shorts, but corrected them. I've also messed up the pads quite a bit, but currently no detectable shorts. Maybe having those short-circuits messed up the JTAG. Maybe inserting it backwards (in a desperate attempt to see any result) messed it up.

After all that treatment, a failed hardware would probably be not so unlikely any more :-).Maybe one of the inputs or outputs got damaged. But from my experience, with most digital parts this happens very rarely during "normal abuse" like shortcuts.