Author Topic: Digispark Arduino programmer killing keyboard and mouse on Mac (Read 16849 times)

benjie · « **on:** January 03, 2013, 11:57:31 pm »

When I run the digispark Arduino IDE and try to program a digispark on my 2011 MBP running OSX 10.8.2, with nothing else connected to USB ports, the built-in keyboard and trackpad freeze up. Then come back to life after a few seconds, but then freeze again about 15 seconds later. This pattern continues not just until I unplug the digispark, but keeps going until I reboot. (!!) The digispark Arduino IDE never seems to see the digispark, and just waits at "Plug in device now..."

This seems to happen even if I don't plug in a digispark, so it could be the programmer.

I also have VirtualBox installed which I know does some interesting stuff regarding capturing USB devices. Not sure if that's relevant.

Thanks for any help!

Bluebie · « **Reply #1 on:** January 04, 2013, 02:33:43 am »

I\'ve had a bit of this trouble, where it freezes just after programming, but it goes away when I unplug it. The problem is this: If your program isn\'t using DigiKeyboard, DigiUSB, or another of the digispark usb libraries (or some other v-usb firmware) when the device boots the user program it starts using the USB data lines for things which aren\'t usb data. Sometimes this confuses the hub on the mac laptops. Usually mac laptops have at least one USB port which connects directly to a root hub, and some others which connect to a secondary hub as well as connecting in the keyboard, trackpad, bluetooth, and webcam. The digispark is confusing this secondary hub, I think. Try using a different usb port and the problem might go away. Also, try not to do anything to pins 3 or 4 unless you really need to - these are the USB pins. Leaving them both as pinMode OUTPUT, digitalWrite LOW, should keep the computer thinking nothing is plugged in to that USB port, and keep it from getting muddled up.

I\'m using a 2011 Macbook Air which has this same trouble, except for the repeating until reboot part. That\'s pretty annoying!

Open up the Console.app in /Applications/Utilities to see a live system log - you\'ll probably see some USB errors around the time when the keyboard stops working. They might be informative?

benjie · « **Reply #2 on:** January 04, 2013, 10:16:21 am »

I have soldered nothing to my Digisparks yet. And interestingly, this problem happens whenever I run the Upload command in Digispark Arduino, even if I never plug in a Digispark! And if I plug in a Digispark without trying to upload to it, everything remains fine. So it seems it\'s a problem with the Digispark upload program, and has nothing to do with Digispark hardware. I don\'t see anything interesting in the console log...

Bluebie · « **Reply #3 on:** January 04, 2013, 05:44:30 pm »

That is interesting. Maybe the digispark upload program is hitting the USB bus looking for a new device so frequently that it\'s crippling the USB stack. It could be made quite a bit less frequent which could hopefully help with this trouble.

benjie · « **Reply #4 on:** January 04, 2013, 10:30:45 pm »

Hi Bluebie,

Thanks for the help. I tried changing this line:

https://github.com/Bluebie/micronucleus-t85/blob/master/commandline/examples/micronucleus.c#L117

from delay(100); to delay(1000); rebuilt and replaced the micronucleus binary, but no change.

But on the upside, I noticed that if I quit the arduino app, I\'m left with a micronucleus instance running. If I kill that off, it looks like I can avoid the reboot, so it\'s not a disaster. It\'s just not quite working yet.

Ben

digistump · « **Reply #5 on:** January 04, 2013, 11:25:50 pm »

@benjie

this is certainly the strangest issue to date... I\'d love to have some helpful suggestion here, but everything else I\'ve seen like this has been directly related to hardware

I\'ve also seen this run without issue on OSX 10.8 and OS X 10.7 (which I have personally) as well as many 2011 MBPs

I feel like there has to be something strange going on with the USB stack here, but I don\'t see how another driver or application would interfere - though if VirtualBox has some sort of passthrough driver installed I suppose it could - I\'d hope that wouldn\'t cause an effect if VirtualBox wasn\'t running though...

Bluebie · « **Reply #6 on:** January 05, 2013, 12:23:05 am »

Yeah I\'ve seen this too - when two programs are refreshing the USB stack waiting for a new device to appear things get a bit funky. I don\'t know why. Maybe there\'s a better way than polling? Anyway if multiple micronucleus instances are running they\'re probably fighting and making race conditions where they each take turns uploading a program to the device before quitting. I think this can happen if you press upload then press it again - I don\'t think the arduino app quits the previous instance of the upload binary

Bluebie · « **Reply #7 on:** January 05, 2013, 12:23:49 am »

@digistump the correct behaviour would be to just force kill the previous instance - it has no state, it can\'t corrupt anything AFAIK.

digistump · « **Reply #8 on:** January 05, 2013, 12:29:30 am »

@Bluebie Do you see any issue with the previous one being killed during an upload?

Bluebie · « **Reply #9 on:** January 05, 2013, 01:56:40 am »

@digistump I can\'t think of any reason why a digispark would be harmed by the host software exiting abruptly or malfunctioning. Maybe there are some bugs in the logic? but if not, it should be protected. One day I\'ll find the motivation to try and break one with usb request fuzzing and maybe shake out a bug - hopefully not though! The logic is pretty straight forward.

benjie · « **Reply #10 on:** January 05, 2013, 05:16:40 pm »

I also added a timeout in my local copy of micronucleus, so that it will only keep trying to connect for 20 seconds, and then fail, instead of trying forever.

benjie · « **Reply #11 on:** January 05, 2013, 05:26:57 pm »

I tried converting micronucleus to use libusb-1.0 instead of 0.1 to see if that helped, but no change. I also have macports installed, but nothing too weird installed through there.

I added some debugging while micronucleus polls for devices, and noticed that it never sees any of my digisparks in the device list when I plug them in. (First 5 seconds.) The list remains the same for both of my 2 usb busses.

Same in the System Information app\'s USB section. Digispark never appears. But the digispark waits 5 seconds and then starts blinking, so I think it\'s healthy...

Bluebie · « **Reply #12 on:** January 05, 2013, 06:16:23 pm »

@benjie can you maybe fork micronucleus on github and post some of your experiments.

benjie · « **Reply #13 on:** January 06, 2013, 08:39:11 am »

@Bluebie I pushed my changes to a fork here:
https://github.com/tripoverzero/micronucleus-t85/tree/master/commandline

Note that I have no idea if it actually works, since I haven\'t been able to get my Digisparks to connect.

Also, a question for you here:
https://github.com/tripoverzero/micronucleus-t85/blob/master/commandline/examples/micronucleus.c#L162

benjie · « **Reply #14 on:** January 06, 2013, 11:55:24 pm »

@Bluebie and @digistump
I feel a bit sheepish now. It looks like the digispark\'s data pins were never connecting because I was plugging it directly into the mac\'s slightly recessed usb ports. The power pins were connecting, so it happily ran its default blinky program, but no data.

I tried plugging it in through a USB extension cable, and it works fine. I still get intermittent mouse and keyboard freezing while micronucleus runs, but this doesn\'t last very long anymore, so it\'s pretty okay.

On a less embarrassing note, my libusb-1.0 conversion seems to have been successful, as it happily reprogramed the digispark first try. I also like the timeout feature I added that stops the micronucleus process from running forever if it doesn\'t find a digispark.

I think I found and fixed a bug that would have broken upload of binary files, which looks like it was a known bug. Haven\'t tested that fix yet though. Comment here:
https://github.com/tripoverzero/micronucleus-t85/blob/master/commandline/examples/micronucleus.c#L162