USB problem with AtmelICE under Linux

Go To Last Post
20 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All,

 

after successfully frying my Atmel JtagIce2 this morning I thought it may be time to get the AtmelICE out of the box (tried that before).

Trouble is it will not talk to me.

 

lsusb finds it:

$ lsusb

...

Bus 002 Device 055: ID 03eb:2141 Atmel Corp. ICE debugger

...

udev rules seem to be correct as well (works fine for all other Atmel programmers):

$ grep -i /etc/udev/rules.d/99-avrisp.rules

ATTR{idVendor}=="03eb", SYSFS{idProduct}=="2141", MODE="660", GROUP="dialout"

user is in group "dialout".

 

But when I start Avrdude I get

avrdude: usb_open(): cannot read serial number "error sending control message: Operation not permitted"

Works fine when I run as root.

 

What have I missed?   What is the difference between the JtagICE2 and the AtmelICE from a USB perspective?

 

 

 

 

Last Edited: Thu. Nov 17, 2016 - 12:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hugo_habicht wrote:
What is the difference between the JtagICE2 and the AtmelICE from a USB perspective?
The group changed :

http://lists.nongnu.org/archive/html/avr-chat/2015-01/msg00003.html

and more in that thread.

via

http://www.nongnu.org/avrdude/ ("How to get help or report bugs")

 

P.S.

hugo_habicht wrote:
after successfully frying my Atmel JtagIce2 this morning ...
Sorry for the loss.

If one drops a conductor into the target and its AVR ISP has an over-volt or short then the JTAGICE2's power supply may have been damaged; some notebook PC have been damaged by such (USB over-current).

It's been stated that a USB isolator should be used between the debugger/programmer and the hub or host.

 

The replacement for an Atmel JTAGICE2 might be either a clone or a function-like.

 

Edit : P.S.

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Thu. Nov 17, 2016 - 01:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I read through the thread in the link and as far as I understand the user had to be in group "uucp" in order to use the JtagICE2.     This programmer worked fine on my system with group dialout.

 

I changed the group of the programmer in the udev rules to "uucp"  and added the user to this group but I am still getting the same error message.
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
It's been stated that a USB isolator should be used between the debugger/programmer and the hub or host.

Must have missed that statement, I'm not here too often.   I promise to improve.

 

Off topic:

Well, I could establish the sequence of events:

 

1. when I increased the output voltage of my cap charger to 350V a rectifier diode rated for 400V got fried (should have thought about the inverse transformer voltage and looking at it retrospectively the safety margin was too low anyway)

2. the melted diode cause an overcurrent in the primary side transistor melting as well

3. the melted transistor made the shunt evaporate

4. with the shunt missing the melted transistor pulled the cap charger IC inputs to 24V and fried that too

5. the charger control inputs lifted the inputs of the Atmel CPU slightly beyond ESD protection limits and caused that to fry as well

6. the Jtag pins also slightly above permitted limits fried the JtagICE drivers

 

1..6 probably happened about 4 orders of magnitude faster that you can say "oops".

 

On topic:

I did some more research:

When I plug in the JtagICE2 "dmesg" reports:

 

$ dmesg

.....

usb 2-1.5: new full speed USB device number 14 using ehci_hcd
usb 2-1.5: New USB device found, idVendor=03eb, idProduct=2103
usb 2-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-1.5: Product: JTAGICE mkII
usb 2-1.5: Manufacturer: ATMEL
usb 2-1.5: SerialNumber: 00B0000057A5
usb 2-1.5: configuration #1 chosen from 1 choice

when I plug in the AtmelICE I get:

$ dmesg

.....

usb 2-1.8: USB disconnect, device number 4
usb 2-1.8: new high speed USB device number 13 using ehci_hcd
usb 2-1.8: New USB device found, idVendor=03eb, idProduct=2141
usb 2-1.8: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-1.8: Product: Atmel-ICE CMSIS-DAP
usb 2-1.8: Manufacturer: Atmel Corp.
usb 2-1.8: SerialNumber: J41800028909
usb 2-1.8: configuration #1 chosen from 1 choice
generic-usb 0003:03EB:2141.0003: hiddev96,hidraw1: USB HID v1.11 Device [Atmel Corp. Atmel-ICE CMSIS-DAP] on usb-0000:00:1d.0-1.8/input0

 

somehow my OS thinks the Atmel programmer is a human interface device.   Is that correct?   Should it be that way?  Or is my interpretation wrong?

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

somehow my OS thinks the Atmel programmer is a human interface device.   Is that correct?   Should it be that way?  Or is my interpretation wrong?

That's correct, all CMSIS-DAP compliant debuggers appear as HID (in the case of the Atmel-ICE, it's actually a USB composite device which has other interfaces as well, but that's beyond the point)

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Would I need the udev entry then?   Maybe that is what is getting in the way?   or do I still have to assign group "uucp"?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hugo_habicht wrote:
Must have missed that statement, ...
Was elsewhere.

Olimex on Wordpress

https://olimex.wordpress.com/2016/06/30/getting-started-with-fpga-with-only-free-and-open-source-software-and-hardware-tools-tutorial/

...

optional but highly recommended USB-ISO – after burning several USB ports on laptops and desktops while playing with development boards now I’m very careful and do not connect anything directly, its very easy to drop tweezers or wire or drop of solder on top of the development board while it’s connected to your computer and the result is USB damage and expensive repair.USB-ISO saves all these troubles and isolate your precious computer from problems with shorts, over voltages etc.

...

An AVR JTAGICE2 is semi-precious wink

hugo_habicht wrote:
6. the Jtag pins also slightly above permitted limits fried the JtagICE drivers
A USB isolator might not prevent that; possible though is a DragonLair if the AVR is via JTAG or ISP.

http://aplomb.nl/TechStuff/Dragon/Dragon.html

LVDS via an Ethernet Base-T transformer might work for JTAG and ISP.

PDI might work via an I2C isolator (single-ended to differential into an Ethernet Base-T transformer) if the PDI clock is reduced to 400KHz or less.

Microchip has an emulator isolator for the MPLAB REAL ICE :

http://www.microchip.com/mplab/emulator-and-debugger-accessories

http://ww1.microchip.com/downloads/en/DeviceDoc/50002529A.pdf

hugo_habicht wrote:
1..6 probably happened about 4 orders of magnitude faster that you can say "oops".
Your choice words are kinder than mine smiley

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
An AVR JTAGICE2 is semi-precious wink

Enlighten me.   I always liked them but after that incident I wanted to bin them and move on.   I have 2, one only worked with PDI (JTAG gone although I had replaced all drivers) and the other with JTAG only (older hardware revision that does not support PDI).

gchapman wrote:
hugo_habicht wrote:
1..6 probably happened about 4 orders of magnitude faster that you can say "oops".
Your choice words are kinder than mine smiley

Well, it happend a day ago, so I had time to calm down a bit.   I think a transcript of my voice at the time of the incident would be removed very quickly due to violation of forum rules...

 

Thank you very much for the hint with the hid library.   I ran .configure for avrdude again and see: "DON'T HAVE' libhid".   So that is missing.  

 

But why does avrdude then run fine with root privileges?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If it works as root and not as normal user udev is often the solution.

Both the vendor Id and Product Id have to be correct.

 

If you've changed the udev rules after last login you have to restart udev to apply your changes.

sudo service udev restart

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

Last Edited: Fri. Nov 18, 2016 - 10:55 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Paul,

 

I agree that udev is most likely the problem.   But the entry is there and the ID is correct (ATTR{idVendor}=="03eb", SYSFS{idProduct}=="2141").  The same entry (with different ID) works fine for the AVRIsp2 and the JtagICE2.   The only difference I see at the moment is the HID type that gchapman pointed out.

 

And yes, I did restart the udev service.    Does the group actually matter?    As far as I see it only has to match the users group somewhere, so if it is uucp or dialout should not matter (tried both).   Or are there subtle differences hidden deep down in the kernel that I am not seeing?

 

Do you (or anybody else out there) have the AtmelICE running under Linux?   If yes, I'd like to see the udev rules entry.

 

Regards,

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Reading:

 

https://wiki.ubuntu.com/Debuggin...

 

then

sudo udevadm monitor --e

sounds like it could be a bit of fun! Or perhaps even:

sudo pkill udevd
sudo udevd --debug-trace --verbose --suppress-syslog 

and of course /var/log/udev sounds like it'd be worth exploring.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi clawson,

 

thank you for the links.    So far running under root gets me out of a hole but that's no long term solution.    It looks I have to delve into that udev stuff which I would have liked to avoid.   Not sure if it's fun though...   I got the feeling that it has to do with the ICE being a HID, that is the only difference to the Jtag2 I can see.   And that may be handled differently on my OS (RHEL), the libhid avrdude is looking for is not there anyway, maybe under a different name.

 

I didn't know about the udev log, it's somewhere else on my OS, so I have to look for it.   At least everything is documented and accessible unlike on other OS with mostly binary proprietary file contents and special software required for every small thing you like to do.

 

Regards,

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hugo_habicht wrote:
At least everything is documented and accessible unlike on other OS with mostly binary proprietary file contents
Indeed - the joy of Linux - even if any part of the system does not already have visibility/logging you can easily take the source and add some and rebuild so you can always work out why things like this device detection don't work. You'd have no hope in the "black box" that is Windows!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hugo_habicht wrote:
Enlighten me.
Price increases; AVR JTAGICE2 due to EOL and Atmel-ICE within Microchip.

This creates opportunities for third parties.

hugo_habicht wrote:
I ran .configure for avrdude again and ...
If AVRDUDE is in your Linux distribution then usually no need for a configure.

http://packages.ubuntu.com/yakkety/avrdude

I apologize for the mis-direct; libusb has HID within it :

http://www.linux-usb.org/devices.html

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hugo_habicht wrote:
Do you (or anybody else out there) have the AtmelICE running under Linux?
Atmel-ICE is operational on AVRDUDE 6.3 and AVaRICE (after 2.13 plus r358) (did not search these for udev) :

http://lists.nongnu.org/archive/cgi-bin/namazu.cgi?query=Atmel-ICE&submit=Search%21&idxname=avr-chat&max=20&result=normal&sort=score

https://sourceforge.net/p/avarice/mailman/avarice-user/?style=threaded&viewmonth=201603&limit=250

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hugo_habicht wrote:
And that may be handled differently on my OS (RHEL), ...
Could not locate AVRDUDE in the package manifest for RHEL 7; now I know why configure occurred.

Are Fedora packages compatible with RHEL?

Yes.

https://wiki.centos.org/HowTos/PackageManagement/YumOnRHEL

but a very cursory search does not have AVRDUDE 6.3 :

https://dl.fedoraproject.org/pub/epel/7/x86_64/a/


https://wiki.centos.org/AdditionalResources/Repositories

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Fri. Nov 18, 2016 - 03:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm running RHEL 6.5 since I do not believe in upgrading (I refer to this process as downgrading) too often.   Usually a lot of time involved.   Never touch a running system.

 

So far I always built avrdude from source and it was always absolutely painless and worked first time.   The AtmelICE is the first time I am having problems.

 

I have to get a project out the door first, then I'll start digging deep into udev to find out why it does not like the new ICE....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
You'd have no hope in the "black box" that is Windows!

I could not agree more !   Endless permutation of settings and parameters and trial and error not leading anywhere.

No black boxes for me ever again...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hugo_habicht wrote:
Does the group actually matter?
No if it's read and write for all (owner, group, world).

The following is for a CDC ACM device instead of HID :

https://github.com/micronucleus/micronucleus/blob/master/commandline/49-micronucleus.rules

...

# If you share your linux system with other users, or just don't like the
# idea of write permission for everybody, you can replace MODE:="0666" with
# OWNER:="yourusername" to create the device owned by you, or with

# GROUP:="somegroupname" and mange access using standard unix groups.

via

https://github.com/micronucleus/micronucleus/tree/master/commandline

 

Teensy 2 can do HID after the CDC ACM for the HalfKay bootloader and loader.

CDC - http://pjrc.com/teensy/49-teensy.rules

HID -

PJRC

C code for Teensy: USB Raw HID - for building custom USB devices

http://pjrc.com/teensy/rawhid.html

...

Linux UDEV Rule

On Linux, unknown devices are not accessible to non-root users. This udev rule can be used to grant access.

SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="0480", MODE:="0666"

...

"Dare to be naïve." - Buckminster Fuller