[SOLVED] "Assertion 'res >=4' failed" error on Ubuntu 12.04 caused by usb permissions issue

[kcbudd]

Posting in case anyone else has the same issue:

I was having this problem on two different machines (one Dell desktop, and one Lenovo T420s laptop) - both running Ubuntu 12.04 64-bit, both with openjdk-6-jre (64 bit), Arduino tools 1.0.3 64-bit, avrdummy and micronucleus command line compiled locally on the system and placed in the arduino package hardware/tools/ directory as instructed.

I was always getting the 'micronucleus_connect: Assertion `res >= 4' failed.' error when I plugged the device in at the 'Plug in device now...' prompt.

While writing this post, I decided to run the arduino IDE under 'sudo' in case it was a usb dev permissions error, and voila - it worked!!  It turns out that the default usb udev rules on my systems were causing the device to show up owned as root with mode 0600.  To alleviate this, I created a custom udev rules file for the digispark using the vendorId and productId fields that I observed when I plugged the device in:

Create a file named /etc/udev/rules.d/digispark.rules  with the following line in it:

SUBSYSTEM=="usb", ATTR{idVendor}=="16d0", ATTR{idProduct}=="0753", MODE="0660", GROUP="dialout"

[Question:  Is this the only / final vendor:product ID combo for the digisparks?]

This will cause the digispark to show up with mode 0660 (-rw-rw----) and owned by group "dialout", which is consistent with how other usb-serial devices show up.  Optionally, you can change the group or the mode if you'd like.  (E.g. MODE="0666" will be writable by any user on the system.)

[digistump]

Awesome - thanks for contributing that, I\'m sure it will help many!

To answer your question the VID/PID pair is the only and final pair for Digisparks that we \"Digistump\" ship.

[tsbertalan]

I still get this error, despite running the arduino IDE as root, and creating these files:


/etc/udev/rules.d/49-micronucleus.rules AND /lib/udev/rules.d/49-micronucleus.rules:

Code: [Select]


SUBSYSTEMS=="usb", ATTRS{idVendor}=="16d0", ATTRS{idProduct}=="0753", MODE:="0666", GROUP="dialout"
KERNEL=="ttyACM*", ATTRS{idVendor}=="16d0", ATTRS{idProduct}=="0753", MODE:="0666", ENV{ID_MM_DEVICE_IGNORE}="1"


/etc/udev/rules.d/90-digispark.rules AND /lib/udev/rules.d/90-digispark.rules:

Code: [Select]


SUBSYSTEMS=="usb", ATTRS{idVendor}=="16d0", ATTRS{idProduct}=="0753", MODE:="0666"
KERNEL=="ttyACM*", ATTRS{idVendor}=="16d0", ATTRS{idProduct}=="0753", MODE:="0666", ENV{ID_MM_DEVICE_IGNORE}="1"


(I also tried sudo cp 90-digispark.rules /etc/udev/rules.d/90-digispark.rules, as suggested by README.udev in the precompiled binary tarball.)


I'm trying to upload the examples/Digispark/Start sketch, but, when I plug in my Digispark kickstarter edition rev2 (when requested to), it gets to 79% in uploading, then fails:

Code: [Select]


Running Digispark Uploader...
Plug in device now...
> Please plug in the device ...
> Press CTRL+C to terminate the program.
> Device is found!
connecting: 40% complete
> Device looks like ATtiny85!
> Available space for user application: 6010 bytes
> Suggested sleep time between sending pages: 8ms
> Whole page count: 94
> Erase function sleep duration: 752ms
parsing: 60% complete
> Erasing the memory ...
erasing: 79% complete
>> Abort mission! -1 error has occured ...
>> Please unplug the device and restart the program.


Two things stand out to me

• It does seem to make some progress before it fails.
• It says "Device looks like ATtiny85", although "Digispark (Tiny Core)" is selected for "Board" and "Digispark" is selected for "Programmer". But this might be by design with the modified avrdude.

I have tried both the precompiled binary packages, and compiling from source(s). I'm on a Samsung NC10 running Ubuntu 12.04.1 with Intel Atom N270. Interestingly, I had to install libusb-dev before I could make micronucleus-t85/commandline, since library/micronucleus_lib.h:33:80 wanted usb.h. However, uninstalling this didn't help.


Any ideas?

[digistump]

@tsbertalan - The Abort Mission -1 error on linux (unlike the Assertion failed one that is related to permissions) - is usually related to a certain distros/copies/combos of linux and hardware/we aren't quite sure yet but it involves linux - issue that seems to be solved by a hub and often specifically a powered hub (sometimes found in thinks like monitors with USB plugs as well) - can you try a hub as well as the various different ports on your machine?


Re: The Digispark being identified as an Attiny85 - that is the chip on the Digispark, the bootloader is open for use with any project which is why it identifies the chip instead of the device - so no issue there.

[boxtec]

I just wanted to confirm this. I am running Debian Squeeze and we only have the same sort of (stone aged) HP stations here. I got the same error Abort mission! -1 error has occured ... with and without different USB Hubs. However disconnecting other stuff that draws from USB helped greatly. Once I removed all USB devices I was able upload repeatedly without problems - with our without USB Hubs.
 
 I also found that when operating on limits, the larger the sketch is the more probable is a failure. While I could upload the Start sketch directly from the Port I needed an (unpowered) USB Hub to upload the Keyboard sample sketch. I can't say if the same hardware works without problems in windows as I have none.
 Also one of the USB Hubs got fairly hot only while programming the Digistump (yes in this short time) which supports the fact that for some computers it probably just draws more current on programming than USB port is willing to source.
 
 Bottomline: Sometimes (presumably only under Linux) it's enough to disconnect everyhting else from USB to make sure all current is available for programming the  DigiStump.

[phord]

Another success story here.  I hope these notes will help some others.


On my Linux laptop:

• I cannot program a DS using my "front" USB ports. The device never shows up.
• I can program the DS using my rear USB port on my laptop, but I have to twist the board a bit to ensure it makes good contact on all four pins.
• I can also program the DS using an external powered hub.

On my Ubuntu Linux desktop at home:

• I can program the DS using the front USB port if I unplug the mouse from the other front USB port.  Can this really be a current draw issue, or is it a protocol interference issue?
• I can program the DS using the rear USB port pretty reliably.
• I can also program the DS using an external unpowered USB hub.

I have difficulty keeping the USB contacts connected, as I mentioned.  I have examined this a bit.  I see a lot of variance between different DS boards in the width of the card edge.  I don't think this is critical to the contact problem, but some of the boards will not even fit into some of my USB ports unless I force it.


I think what does matter is the USB device shield which is missing on the DS boards.  The shield is not just important for EMI, it seems, but it is also very important to ensure a clean connection between the device and host pins.  Without it, it seems like there is just too much wiggle room in the USB connection slot, and the card is able to move around a lose contact with some of the pins -- usually the data pins, it seems.


I came up with a solution to help me eliminate the physical connection while testing for other problems:
https://plus.google.com/photos/114012580170469677371/albums/5848922926959020145

[HermannSW]

Today I received my first Digispark ATtiny85 micro USB modules.

I had to add the rule kcbudd initially posted on Ubuntu 16.04 with Arduino IDE 1.6.10 in order to not having to run Arduino IDE with sudo. But I had to use mode 0666.

Unfortunately every other upload does end in ">> Flash erase error -32 has occured ...", but the following upload attempt always succeeded. And it works only if I unplug the USB cable before trying to upload.