ARM-USB-TINY-H Problems on Ubuntu

[pmendham]

I have an ARM-USB-TINY-H which I am trying to use on Ubuntu 12.04 LTS 32-bit. I have libusb and libftdi installed but when I plug in the programmmer it does not seem to be loading the driver and no dev node is created (there is no ttyUSB0). lsusb shows that the device is inserted and recognised but I can't do anything with it. any ideas?

TIA

[JohnS]

I don't think it makes a tty of any kind.

What are the VID & PID?

What have you tried to do that fails?  Have you tried, for example, OpenOCD?  It should just work.

John

[pmendham]

Hi John,

Thanks for your reply. I have tried to use OpenOCD which says that the interface was not found. The output from OpenOCD is the same whether the adapter is plugged in or not.

In fact, the contents of /dev are identical whether the adapter is plugged in or not. I assume that a device node must be created for the adapter, otherwise I'm not sure how OpenOCD would access it. Also, in past situations like this I have usually had to create a udev rule to ensure that the permissions on the device node allow the device to be accessed by non-root users. I was using an Amontec JTAGKey-Tiny which was working fine for me (but was on loan). This created a ttyUSB and worked fine with OpenOCD once I had created a suitable udev rule file.

lsusb tells me that the adapter is connected and is, at some level, functional:

Bus 002 Device 014: ID 15ba:002a Olimex Ltd. ARM-USB-TINY-H JTAG interface

But /var/log/syslog seems empty of anything useful when the device is plugged in (no driver is reported as being loaded).

Any ideas?

TIA

[JohnS]

You don't need a /dev thing so much as permission to access the usb thing.

I think what you're missing is a udev rule (e.g. in /etc/udev/rules.d)

Such as
ATTR{idVendor}=="15ba", ATTR{idProduct}=="002a", MODE="0660",GROUP="plugdev"

You need to be in the group so may have to log out & in after adding the group to your user name.

I'd expect what you have now to work for root only (because libusb would find the usb thing and have no permission problem).

John

[pmendham]

Hi John,

So from reading around a bit more, it looks like I was confused about needing a /dev/ttyUSB. Just like you said, it sounds like it's not necessary. Sorry for barking up the wrong tree.

The problem I'm having is not with permissions, though. When I plugged in the adapter just now lsusb says:

Bus 002 Device 020: ID 15ba:002a Olimex Ltd. ARM-USB-TINY-H JTAG interface

I have the following udev rule (/etc/udev/rules.d/99-usb-tiny.rules):

SUBSYSTEMS=="usb", ATTRS{idVendor}=="15ba", ATTRS{idProduct}=="002a", MODE="0666", GROUP="plugdev"

If I check in /dev/bus/usb/002/020 I see the device node for the adapter:

$ ls -l /dev/bus/usb/002/020
crw-rw-rw- 1 root plugdev 189, 147 Mar  2 20:37 /dev/bus/usb/002/020

It has picked up the correct permissions and group from my udev rule.

If I run openocd it says:

Error: unable to open ftdi device: device not found

If I run openocd as sudo it says exactly the same thing. If I run openocd without the adapter plugged in it also says exactly the same thing. It seems like the device is not being found by libftdi. Any ideas why not?

TIA

[JohnS]

All looks OK so far, so...

Next idea: openocd built without the needed support.  (It's easily done.)

The config.log shows how it was built, near the top.

John

[pmendham]

Hi John,

My config.log from my openocd build shows that I used the following configuration:

$ ./configure --enable-maintainer_mode --enable-ft2232_libftdi

Which matches what I thought I used for the openocd build. Did I do the right thing?

Some more information: I dug around in the documentation for libftdi-dev and spotted some example code, including an example called find_all.c. From the source it looks like this just lists attached FTDI devices. I built it and ran it and it tells me that there are no FTDI devices attached, even though my adapter is plugged in. This might be a red herring, in which case sorry, but I did wonder if it is another example of the same problem.

TIA

[pmendham]

Actually, a correction to that last bit of information. I didn't read the find_all code properly, sorry. If I set the VID/PID correctly in the find_all source it does find the adapter using libftdi. Interestingly, if I link against libftdi (-lftdi, the same as openocd) I get some errors. If I link against libftdi1 (-lftdi1) I don't get those problems. Should openocd be using libftdi1? This is probably a red herring again...

[JohnS]

I think you've asked for a deprecated FTDI that's not necessarily part of the device you're using.

I used
./configure --enable-ftdi

and some others that I use but not relevant here

You may want to ask on the oocd ML and/or get a very recent build (if you haven't now) or at least check what the option you've chosen means.  I'm not sure it's the old horrid FTDI code but I think it is.

John

[pmendham]

Hi John,

Thanks for your help. I'm not sure I understand why it's now working, but it seems to be. I used the --enable-ftdi option you suggested and all is now fine. I'd love to know what exactly the problem was but I'm afraid to play with anything - it works and I'm just going to get on with using it now!

Thanks again.

[JohnS]

Working is good!

I think the kind of FTDI you had enabled sends the code through a very different set of routines whereas the newer one goes through rewritten and much more generic FT2232 etc support code.

John