Error uploading code with IDE 1.6.7 to Genuino 101

Today I got the brand new Genuino 101. Therefore I installed the IDE 1.6.7, added the Intel Curie board and selected COM6 (Arduino 101). Choosing an example put of the box everything should be fine. Unfortunately I got this error log after compiling and uploading:

Der Sketch verwendet 29.525 Bytes (15%) des Programmspeicherplatzes. Das Maximum sind 196.608 Bytes.
starting download script
Args to shell: C:\Users\Beat Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/x86/bin C:\Users\BEATAR~1\AppData\Local\Temp\build023cce891d1216b764cf98b839ed023f.tmp/sketch_dec29a.ino.elf COM6 quiet
Serial Port PORT
BIN FILE C:\Users\BEATAR~1\AppData\Local\Temp\build023cce891d1216b764cf98b839ed023f.tmp/sketch_dec29a.ino.bin
Waiting for device... 
C:\Users\Beat Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/clupload/cluploadArduino101_win.sh: line 36: $tmp_dfu_output: ambiguous redirect
FINDSTR: C:\Users\Beat kann nicht ge”ffnet werden.
FINDSTR: Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/x86/bin\..\..\.tmp_dfu_output kann nicht ge”ffnet werden.
C:\Users\Beat Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/clupload/cluploadArduino101_win.sh: line 41: C:/Users/Beat: No such file or directory
C:\Users\Beat Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/clupload/cluploadArduino101_win.sh: line 42: $tmp_dfu_output: ambiguous redirect
FINDSTR: C:\Users\Beat kann nicht ge”ffnet werden.
FINDSTR: Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/x86/bin\..\..\.tmp_dfu_output kann nicht ge”ffnet werden.
C:\Users\Beat Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/clupload/cluploadArduino101_win.sh: line 41: C:/Users/Beat: No such file or directory
C:\Users\Beat Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/clupload/cluploadArduino101_win.sh: line 42: $tmp_dfu_output: ambiguous redirect
FINDSTR: C:\Users\Beat kann nicht ge”ffnet werden.
FINDSTR: Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/x86/bin\..\..\.tmp_dfu_output kann nicht ge”ffnet werden.
C:\Users\Beat Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/clupload/cluploadArduino101_win.sh: line 41: C:/Users/Beat: No such file or directory
C:\Users\Beat Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/clupload/cluploadArduino101_win.sh: line 42: $tmp_dfu_output: ambiguous redirect
FINDSTR: C:\Users\Beat kann nicht ge”ffnet werden.
FINDSTR: Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/x86/bin\..\..\.tmp_dfu_output kann nicht ge”ffnet werden.
C:\Users\Beat Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/clupload/cluploadArduino101_win.sh: line 41: C:/Users/Beat: No such file or directory
C:\Users\Beat Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/clupload/cluploadArduino101_win.sh: line 42: $tmp_dfu_output: ambiguous redirect
FINDSTR: C:\Users\Beat kann nicht ge”ffnet werden.
FINDSTR: Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/x86/bin\..\..\.tmp_dfu_output kann nicht ge”ffnet werden.
C:\Users\Beat Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/clupload/cluploadArduino101_win.sh: line 41: C:/Users/Beat: No such file or directory
C:\Users\Beat Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/clupload/cluploadArduino101_win.sh: line 42: $tmp_dfu_output: ambiguous redirect
FINDSTR: C:\Users\Beat kann nicht ge”ffnet werden.
FINDSTR: Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/x86/bin\..\..\.tmp_dfu_output kann nicht ge”ffnet werden.
C:\Users\Beat Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/clupload/cluploadArduino101_win.sh: line 41: C:/Users/Beat: No such file or directory
C:\Users\Beat Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/clupload/cluploadArduino101_win.sh: line 42: $tmp_dfu_output: ambiguous redirect
FINDSTR: C:\Users\Beat kann nicht ge”ffnet werden.
FINDSTR: Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/x86/bin\..\..\.tmp_dfu_output kann nicht ge”ffnet werden.
C:\Users\Beat Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/clupload/cluploadArduino101_win.sh: line 41: C:/Users/Beat: No such file or directory
C:\Users\Beat Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/clupload/cluploadArduino101_win.sh: line 42: $tmp_dfu_output: ambiguous redirect
FINDSTR: C:\Users\Beat kann nicht ge”ffnet werden.
FINDSTR: Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/x86/bin\..\..\.tmp_dfu_output kann nicht ge”ffnet werden.
C:\Users\Beat Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/clupload/cluploadArduino101_win.sh: line 41: C:/Users/Beat: No such file or directory
C:\Users\Beat Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/clupload/cluploadArduino101_win.sh: line 42: $tmp_dfu_output: ambiguous redirect
FINDSTR: C:\Users\Beat kann nicht ge”ffnet werden.
FINDSTR: Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/x86/bin\..\..\.tmp_dfu_output kann nicht ge”ffnet werden.
C:\Users\Beat Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/clupload/cluploadArduino101_win.sh: line 41: C:/Users/Beat: No such file or directory
C:\Users\Beat Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/clupload/cluploadArduino101_win.sh: line 42: $tmp_dfu_output: ambiguous redirect
FINDSTR: C:\Users\Beat kann nicht ge”ffnet werden.
FINDSTR: Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/x86/bin\..\..\.tmp_dfu_output kann nicht ge”ffnet werden.
C:\Users\Beat Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/clupload/cluploadArduino101_win.sh: line 41: C:/Users/Beat: No such file or directory
C:\Users\Beat Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/clupload/cluploadArduino101_win.sh: line 42: $tmp_dfu_output: ambiguous redirect
FINDSTR: C:\Users\Beat kann nicht ge”ffnet werden.
FINDSTR: Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/x86/bin\..\..\.tmp_dfu_output kann nicht ge”ffnet werden.
ERROR: Timed out waiting for Arduino 101.

Two things that are strange:
1: Why is there a new line between the first and the family name? Can the upload tool not handle a path with a space? But this worked fine in older versions.
2: Why is there a timeout waiting for Arduino 101.

BTW: The error remains in the hourly build 1.6.8.

Thanks for any help and kind regards

Beat Arnet

Today I could reproduce the error on another computer running Win7 instead of Win10 and using another USB-cable. Both times I tested with the stable version 1.6.7 and the nightly build from 2015/12/30.

I think the problem is definitely caused by the space in your user folder. A fix for this issue(ATLEDGE-464 SketchUpload recognizes Windows paths with spaces by bbaltz505 · Pull Request #20 · intel/intel-arduino-tools · GitHub) has already been submitted to the appropriate repository but has not yet been merged. You can manually make the changes to your C:\Users\Beat Arnet\AppData\Local\Arduino15\packages\Intel\tools\sketchUploader\1.6.4+1.14/clupload/cluploadArduino101_win.sh as shown here: ATLEDGE-464 SketchUpload recognizes Windows paths with spaces · bbaltz505/intel-arduino-tools@bd207be · GitHub

EDIT: the pull request fixing this issue was merged 2016-01-05. This issue should be fixed if you are using the latest version of Intel Curie Boards.

Actually you should be able to just replace the file with this one, that should be easier since there are 2 commits in that PR: https://raw.githubusercontent.com/bbaltz505/intel-arduino-tools/windows/clupload/cluploadArduino101_win.sh

EDIT: the pull request fixing this issue was merged 2016-01-05. This issue should be fixed if you are using the latest version of Intel Curie Boards.

@pert

Thanks a lot. I only had to replace the file and everything works fine.

Kind regards

Beat

I have what would seem to be the same issue but on a Mac book Pro. done the following.

  1. Downloaded 1.6.7 and updated with 1.6.8. and hourly update.
  2. installed and removed Arduino IDE a few times
  3. rebooted both Mac and Arduino IDE. a number of times
  4. Changed USB lead.
  5. Read and attempted fix listed in thread and code on Github (until i realised it was for a PC)Duh

Macbook Pro
Running 10.11.2 El capitan

Genuino 101 (came direct from Genuino brand new )

In addition

Com port seems ok
also downloaded curie board files from board manager

jamierowl:
I have what would seem to be the same issue but on a Mac book Pro. done the following.

Please post the output you are getting in the console using the code tags(</> button)

Sorry for not sending before all a bit frustrating and working late :slight_smile:

Sketch uses 39,188 bytes (19%) of program storage space. Maximum is 196,608 bytes.
Starting upload script
Payload: /var/folders/0d/jrbj1yr145v3k077k6tgwlt40000gn/T/buildffd28ae8d0c329a1b38b650c79010392.tmp/SetTime.ino.bin
Waiting for device...
ERROR: Timed out waiting for Arduino 101.

Ok, that wasn't very helpful output. Could you try with verbose output checked in File > Preferences please, hopefully that will give some clues.

Sorry not done a verbose output before Learnt something thanks for that.
Hope this text gives some more clues

ketch uses 39,188 bytes (19%) of program storage space. Maximum is 196,608 bytes.
/bin/bash --noprofile /Users/puds13/Library/Arduino15/packages/Intel/tools/sketchUploader/1.6.4+1.14/clupload/cluploadArduino101_osx.sh /Users/puds13/Library/Arduino15/packages/Intel/tools/sketchUploader/1.6.4+1.14/x86/bin /var/folders/0d/jrbj1yr145v3k077k6tgwlt40000gn/T/buildffd28ae8d0c329a1b38b650c79010392.tmp/SetTime.ino.elf /dev/cu.usbmodem1D11 verbose
Starting upload script
Payload: /var/folders/0d/jrbj1yr145v3k077k6tgwlt40000gn/T/buildffd28ae8d0c329a1b38b650c79010392.tmp/SetTime.ino.bin
Waiting for device...
ERROR: Timed out waiting for Arduino 101.

That looks like it's a different issue from the one arbel had because your user name doesn't have a space in it which was the cause of that issue.

Thanks, was able to get the Arduino 101 to communicate after swapping in the new file. Thanks!

I have experienced the same upload problem on a Win10 PC on my Arduino 101 and I discovered some interesting facts.

While I'm a blog newbie, I have worked in electronics since the '70's when I built my own 8008 (NOT 8080!) micro for my college senior design project.

My original research on this bug included graphic screen captures, which I won't be able to use here (but they are available if needed). I will try to explain everything without the graphics. Maybe this note will help Intel and/or anyone else to figure out the additional pieces of this puzzle that I have yet to find.

This all started when I tried the blink example to test my new Arduino 101. I started by using the board manager to add the Intel Curie. I then loaded the example blink code. Clicked the compile and load button, when it started the downloading, there was a long pause which ALWAYS ended with these error messages each time I tried:

Waiting for device...
Cannot open DFU device 8087:0aba
Cannot open DFU device 8087:0aba
Cannot open DFU device 8087:0aba
ERROR: Timed out waiting for Arduino 101.

I noticed that when I connect the 101 board, there are THREE sets of audio annunciations, the third being delayed several seconds. A normal USB device only generates two: [1] USB inserted, and [2] USB driver started (or so I think). Using Microsoft's free USBView program, I saw that this was indeed an Intel USB driver:

idVendor: 0x8087
idProduct: 0x0AB6
bcdDevice: 0x8087
iManufacturer: 0x01
0x0409: "Intel"
iProduct: 0x02
0x0409: "ARDUINO 101"

(Some may recall 8087 as Intel's old 8086 math coprocessor designation.) The 8087:0aba in the error message is NOT using the Intel Arduino 101 PID of 0x0AB6. More on that later. I googled and found a list of USB vendor IDs kept by none other than the fine people who maintain Linux and that list shows 0x8087 “belongs” to Intel.

I found that what the Arduino IDE saw as the 101's com port was identified by device manager as a Teensy com port driver and not Intel. I then recalled using the board manager to install Teensy on this PC BEFORE adding the Intel Curie. Later, I had the Win10 control panel for "printers and devices" open while playing some more and noticed that when I unplugged the 101 and plugged it back in, it MOMENTARILY shows "Arduino 101" and then after that third audio annunciation it changed to Teensy!

That "official" Linux list shows Teensy using 18 PIDs (product IDs) for USB drivers but all use a VID of 0x16c0 registered to Van Ooijen Technische Informatica and not the 0x8087. So why is my PC showing the Teensy driver as using a VID of 0x8087? That is part of the mystery.

Being stuck, I decided to try something else. I wanted to test a theory: will the 101 work on a PC that never had the Teensy driver installed (via the board manager)? So I tried running the "blink" test on a "clean" laptop. It loaded and ran fine --- most of the time! I guess Intel still has some (timing?) problems with their driver software. I found out that the Intel driver uses a "backdoor" to change the port's baud rate from the default of 9.6 kbps to 57.6 kbps "momentarily" for uploads by first changing the baud rate to 1.2 kbps which causes the Arduino 101 to (quickly?) reset itself so it can then run the bootloader and download the program (if I understand it correctly).

Now I need find out how to I get rid of that interfering Teensy driver on my main PC. Since I had used FTDI's driver removal tool in the past, I thought I would give that a try, but it just removes everything with a specific VID/PID pair and that would get rid of Intel's driver too, so I haven't tried that (yet).

The Arduino website indicates "This (loading) problem does not occur on Linux", I don't think that it takes into account what I found, so it's possible the problem could exist on Linux.

So why doesn't the Teensy driver work? Because it knows nothing about that backdoor to get the 101 to load code. I think that is done via a special downloaded script (intel-arduino-tools/cluploadArduino101_win.sh at 4fa4d12957d397e938721f0e44dec6abe1685c5d · intel/intel-arduino-tools · GitHub). I'm not a Linux guy (mostly deep embedded with a little PC), but I noticed that the script above has the line:
dfu_cmd="$dfu -d8087:0ABA"

So THAT'S where the earlier 0aba came from! A quick search revealed that the dfu command is Linux's Device Firmware Upgrade command for AVR (and apparently Intel) processors. So that implies the Curie has a mini version of Linux running.

In spite of me spending several hours on this, that's as far as I got so far. I originally thought "blink" would take a few minutes. Boy was I wrong! Hope it helps someone to figure out the rest!

At least for now, I can use the other PC to play with my Arduino 101, but I still want it to work on my main PC!

I finally got my Arduino 101 to work consistently. I'm not completely sure which step below was the one that "fixed" it, but I tried 4 things, in the following order:
[1] Recall that I stated my com port was always switching from the 101 to the Teensy driver. I went to the PJRC web site and found a note about uninstalling the Teensy serial driver "that is no longer needed on Windows 10". The step I failed to do before when uninstalling the driver was to check the "delete driver" checkbox BEFORE uninstalling. Now when the port came up, it was the Windows generic serial driver. PJRC's instructions are here: How to delete the Teensy USB Serial driver from Windows 10. Now, when trying it would momentarily come up with the 101 driver and then get replaced with the Windows generic serial driver, so the Teensy driver is at least gone now.
[2] Next, I recalled that the moderator posted something about Windows certificates under "[Win] drivers installation issues". So I did that and with no apparent effect on the driver problem.
[3] Then thinking that the initial installation failed in someway (i.e. blocked by the Teensy driver), I uninstalled the Curie board from the IDE, exited, reinstalled the Curie board, exited and tried downloading again. This time, it seemed to remain the 101 driver longer before, but yet again, it reverted back to the Windows generic serial driver.
[4] Finally, in desperation, I recalled the moderator's recommendation of "press master reset every 3 seconds or so when downloading. Doing that, the first two downloads failed again, but then I noticed in the device manager window, that that port was now saying "Arduino 101 Serial Monitor" and NOT reverting to the Windows default serial driver. This time, when I downloaded again, it worked! I loaded another sketch, downloaded, and IT WORKED TOO. So maybe my main PC is now finally working with the 101 as is should have in the first place.

Hope this helps someone else! Now I wonder if this will work right with my Teensy?

@pert, this showed up in Report to Moderator...

This link is broken

...regarding your post above...

http://forum.arduino.cc/index.php?topic=368654.msg2542845#msg2542845

The fix was merged into the main repository. The relevant commits are:

and

That was back in January so I'm sure the issue is solved in the latest Intel Curie Boards release.

I have edited my previous posts to note this.

Thank you.