I have an arduino board (nano) connected to my Raspberry Pi via the USB port. If I boot the Raspbery Pi first then plugin my arduino it works fine , the arduino is recognised as "FTDI Serial" and assigned to /dev/ttyUSB0.

However if the power goes off and both devices reboot together the Raspberry Pi doesnt detect the arduino at all. The only trace is the following errors in dmesg

[    3.345596] usb 1- new full-speed USB device number 7 using dwc_otg
[    3.445581] usb 1- device descriptor read/64, error -32
[    3.655612] usb 1- device descriptor read/64, error -32
[    3.865636] usb 1- new full-speed USB device number 8 using dwc_otg
[    3.965653] usb 1- device descriptor read/64, error -32
[    4.175541] usb 1- device descriptor read/64, error -32
[    4.385593] usb 1- new full-speed USB device number 9 using dwc_otg
[    4.805417] usb 1- device not accepting address 9, error -32
[    4.905650] usb 1- new full-speed USB device number 10 using dwc_otg
[    5.325409] usb 1- device not accepting address 10, error -32
[    5.326977] hub 1-1.3.1:1.0: unable to enumerate USB device on port 4
[   12.167081] EXT4-fs (mmcblk0p2): recovery complete
[   12.174735] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[   12.177542] VFS: Mounted root (ext4 filesystem) on device 179:2.

I'm pretty sure that it doesnt work because the driver isnt yet available due to the unclean shutdown and subsequent recovery. It works OK if the Pi is cleanly shutdown and then power cycled.

I tried modprobe ftdi_sio after an unclean shutdown - it completed without error but doesnt fix the problem- /dev/ttyUSB0 is still missing.

Is there a way to force a rescan ? A way to unplug and replug the device in software? Most of the solutions I've found seem to rely on being able to locate the device in /sys/bus/usb/devices but its not present.

4 Answers 4


Device descriptor read error can indicate the USB device is not getting enough power. I saw this error trying to run Arduino from a desktop USB. Ultimate solution was to put it on a powered USB hub.



I just assume you are using raspbian. The /dev/ names are normally assigned by udevd - so restarting this with /etc/init.d/udev restart might help.


Apparently the cause of this issue is a hardware bug with the Arduino Nano and clones, as discussed in this thread: "After rebooting, Arduino Nano that connects to RPi not found"

The "Test" pin is supposed to be tied to ground and on early versions of the Arduino Nano V3.0 and most versions of the clones this pin is left unconnected.

The workaround is to put "a solder bridge between pin 25 and pin 26" of the FTDI chip.

I've chosen to use this hardware solution rather than try to get the USB reset to work. It requires a steady hand, fine tipped soldering iron, magnification and a tiny amount of solder.

Note the original (2009) schematic: arduino.cc/en/uploads/Main/ArduinoNano30Schematic.pdf

And the updated (2010) schematic with the fix applied: http://site.gravitech.us/Arduino/NANO30/ArduinoNano3_0schematic.pdf


I know that this is an old thread, but maybe my experience can help someone that facing the same problem.

Actually, I got the same problem but not with RPi, my problem with Arduino nano and OpenWrt. Nano can be recognized when hot plugging, but not when plug in before OpenWrt booting.

My problem solved with delaying OpenWrt boot process to give nano finishing it own boot process. At OpenWrt, give a longer value at preinit file, fs_failsafe_wait_timeout to bigger enough value. For RPi, find the file that responsible for early boot and add necessary delay to it.

  • 1
    Hello and welcome, care to elaborate a little more to make that answer a little more understandable?
    – Ghanima
    Commented Jan 13, 2015 at 22:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.