openocd and panda es difficulties

Hi guys,

I bought a Panda ES to play around with both ARM and dual core processors. Kind of self-education.

I’m hitting a bone though.

I need a hardware debugger. I have started with a bus-blaster v2.5 and got this problem in openocd :

Error: 388 4415 ft2232.c:591 ft2232_read(): couldn't read enough bytes from FT2232 device (0 < 81)

I googled around and could not find anything relevant.

I recompiled:

  • libftdi 0.20

  • openocd 0.6

on my ubuntu 12.04 32 bit machine

Then I read that bus-blaster was somewhat experimental and so I decided to blame it.

I bought a shiny new flyswater2. It seems to be more established than the bus-blaster and it comes with a case.

Plugged it and doh… same thing.

Here it is:

sudo openocd -f interface/flyswatter2.cfg -f board/ti_pandaboard_es.cfg
Open On-Chip Debugger 0.6.0 (2012-09-29-14:42)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
RCLK - adaptive
Using dbgbase = 0x80000000
force hard breakpoints
trst_only separate trst_push_pull
Info : max TCK change to: 30000 kHz
Info : RCLK (adaptive clock speed)
Error: couldn't read enough bytes from FT2232 device (0 < 81)
Error: couldn't read from FT2232
in procedure 'runtest'
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: couldn't read enough bytes from FT2232 device (0 < 2)
Error: couldn't read from FT2232
Warn : Bypassing JTAG setup events due to errors

I have checked what I could think of :

  • yes, the panda is powered (happens)

  • I have checked about 3 times the connections between the flyswatter2 and the panda. Unfortunately I could not buy the adapter because watterott was out of them.

  • openocd seems to be using the correct libraries:

ldd /usr/local/bin/openocd	linux-gate.so.1 =>  (0x005b2000)
	libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0x00429000)
	libftdi.so.1 => /usr/local/lib/libftdi.so.1 (0x00ae7000)
	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00110000)
	/lib/ld-linux.so.2 (0x00a7c000)
	libusb-0.1.so.4 => /lib/i386-linux-gnu/libusb-0.1.so.4 (0x00ebd000)
  • emu 0 and 1 are left floating

I’ve run the command again with the “-d 3” option but:

  • I don’t really know what to expect when it runs ok,

  • the log is about 40kB so I don’t know if I am allowed to post it here…


Update 20121006:

I have tried to compile openocd against the proprietary drivers. It was not so much fun but I got it in the end and the result is really disapointing.

Open On-Chip Debugger 0.6.0 (2012-10-06-16:42)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
RCLK - adaptive
Using dbgbase = 0x80000000
force hard breakpoints
trst_only separate trst_push_pull
Info : device: 6 "2232H"
Info : deviceID: 67330064
Info : SerialNumber: FS20000A
Info : Description: Flyswatter2 A
Info : max TCK change to: 30000 kHz
Info : RCLK (adaptive clock speed)
Error: couldn't read enough bytes from FT2232 device (0 < 81)
Error: couldn't read from FT2232
in procedure 'runtest'
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: couldn't read enough bytes from FT2232 device (0 < 2)
Error: couldn't read from FT2232
Warn : Bypassing JTAG setup events due to errors

The flyswatter2 is definitely working fine, at least on the USB side. Using the examples provided with the proprietary drivers at least. I can read the EEPROM no problem

libftd2xx1.1.12/examples/EEPROM/read$ sudo ./read
Library version = 0x10112
Opening port 0
FT_Open succeeded.  Handle is 0x82cb238
FT_GetDeviceInfo succeeded.  Device is type 6.
FT_EE_Read succeeded.

Signature1 = 0
Signature2 = -1
Version = 3
VendorId = 0x0403
ProductId = 0x6010
Manufacturer = TinCanTools
ManufacturerId = FS
Description = Flyswatter2
SerialNumber = FS20000
MaxPower = 90
PnP = 1
SelfPowered = 0
RemoteWakeup = 0
Returning 0

---- end of update


Update 20121008:

I’ve made some progress but I’ll keep the cider in the fridge for now.

I’m sticking to the proprietary drivers because they give me results.

I have tried on a different machine (ubuntu again but 64 bit this time) and I have compiled the new openocd 0.6.1.

Not much change there I get the same result.

HOWEVER, if I start openocd and then power on the panda board, I get this :

sudo openocd -f interface/flyswatter2.g -f board/ti_pandaboard_es.cfg
Open On-Chip Debugger 0.6.1 (2012-10-08-17:47)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
RCLK - adaptive
Using dbgbase = 0x80000000
force hard breakpoints
trst_only separate trst_push_pull
Info : device: 6 "2232H"
Info : deviceID: 67330064
Info : SerialNumber: FS20000A
Info : Description: Flyswatter2 A
Info : max TCK change to: 30000 kHz
Info : RCLK (adaptive clock speed)
Info : JTAG tap: omap4460.jrc tap/device found: 0x0000002f (mfg: 0x017, part: 0x0000, ver: 0x0)
Warn : JTAG tap: omap4460.jrc       UNEXPECTED: 0x0000002f (mfg: 0x017, part: 0x0000, ver: 0x0)
Error: JTAG tap: omap4460.jrc  expected 1 of 2: 0x2b94e02f (mfg: 0x017, part: 0xb94e, ver: 0x2)
Error: JTAG tap: omap4460.jrc  expected 2 of 2: 0x1b85202f (mfg: 0x017, part: 0xb852, ver: 0x1)
Error: Trying to use configured scan chain anyway...
Warn : Bypassing JTAG setup events due to errors

I guess I am getting one byte closer… :?

---- end of update

Now I’ve run out of idea.

Any help, lead, idea would be appreciated.

Thanks,

Fred.

Reading the user manual can be a good idea in fact.

6.2.4 JTAG Clock Rate

Before your reset-init handler has set up the PLLs and clocking, you may need to run with a low JTAG clock rate. See JTAG Speed. Then you’d increase that rate after your handler has made it possible to use the faster JTAG clock.

Now replacing in board/ti_pandaboard_es.cfg

jtag_rclk 6000

with

adapter_khz 50

is fixing the problem.

I’ve created a new file board/ti_pandaboard_es_slow.cfg in fact for when I debug the bootloader part. Now I can finally play with the board.