Cannot communicate with Sparki (Windows/Linux)


I’m actually asking this for my son - since I cannot figure it out myself.

He has a brand new Sparki and it seems to be blocked after first attempts to program it (upload an example sketch). The behaviour is the same under Windows or Linux, with Arduino IDE v 1.8.5 (“Connecting to programmer: .avrdude: butterfly_recv(): programmer is not responding” while trying to upload new code).

Sparki status LED is blinking (fade in/out). Since it’s easier (at least for me) to get low-level details with Linux, here is what I can get so far on Linux. It seems that Sparki disconnects after a few seconds. Here is dmesg output:

[ 1334.834571] usb 3-1.2: New USB device found, idVendor=27c2, idProduct=0003 [ 1334.834572] usb 3-1.2: New USB device strings: Mfr=2, Product=1, SerialNumber=0 [ 1334.834573] usb 3-1.2: Product: Sparki [ 1334.834573] usb 3-1.2: Manufacturer: ArcBotics LLC [ 1334.835184] cdc_acm 3-1.2:1.0: ttyACM0: USB ACM device [ 1342.524746] usb 3-1.2: USB disconnect, device number 10 [ 1342.524821] cdc_acm 3-1.2:1.1: urb 11 failed submission with -19 [ 1342.526781] cdc_acm 3-1.2:1.1: urb 12 failed submission with -19 [ 1342.530787] cdc_acm 3-1.2:1.1: urb 13 failed submission with -19 [ 1342.532809] cdc_acm 3-1.2:1.1: urb 14 failed submission with -19 [ 1342.534806] cdc_acm 3-1.2:1.1: urb 15 failed submission with -19

Looking around on this forum, I’ve read Cannot Upload to Sparki in Linux I’ve then added a udev rule and re-started daemon, and globally I have the same result when I reset Sparki (using the push button) - device gets disconnected and I cannot upload any code from Arduino IDE - except cdc_adm is no longer reporting any error:

[ 1775.223128] usb 3-1.3: new full-speed USB device number 12 using xhci_hcd [ 1775.324836] usb 3-1.3: New USB device found, idVendor=27c2, idProduct=0003 [ 1775.324837] usb 3-1.3: New USB device strings: Mfr=2, Product=1, SerialNumber=0 [ 1775.324838] usb 3-1.3: Product: Sparki [ 1775.324839] usb 3-1.3: Manufacturer: ArcBotics LLC [ 1775.325343] cdc_acm 3-1.3:1.0: ttyACM0: USB ACM device [ 1782.895675] usb 3-1.3: USB disconnect, device number 12

So… I don’t know what to do next. I’m not at all a specialist but I’m quite used to Linux commandline, so I any suggestion would be welcome!


OK, should I read everything before, did the trick :unamused: (and, yes, one has to try multiple times to get the right timing!)

I still have to figure out how we got into this state though.


I had this problem too. I am betting the problem was I put a “printf” on the output com port, which interrupts the flow of the resetting and debugging. I did this through ArduBlock which has a nice little “print to serial port” block.

I don’t yet have the bluetooth COM port monitoring or anything else. I imagine when I get that rolling, the prints will happen to Bluetooth and not interrupt the hardware serial port.

I am also thinking I’ll probably use the remote. Then I can have a delay-loop checking for program start, which will allow me to always upload no matter what I do to COM.

Once I switched back to one of the example programs, I had no problems uploading again.

I would make one comment about the website for manual uploads. It says “release the button when the download starts”. What actually shows up in SparkiDuino is a message like PORTS {} / {} => {}. This makes sense because since the Sparki is offline, the port has been removed by the OS in Windows. Once the button is released, the port is found, the programming starts, and this happens before the program starts running ( and potentially offending serial prints start ) and all is good.