Go Down

Topic: Arduino 101 Error: device not responding. (Read 28985 times) previous topic - next topic

ballscrewbob

Sometimes just hitting "reset" (not master reset) on the first fail is enough to kick start the darn thing.

In doing that make sure its is a simple sketch such as BLINK or MINIMUM from examples.

is there a specific reason you are not up to 1.8.2 or 1.8.3 for the IDE ?

Not found any difference in operation for the 101 on those releases here.

Btw please learn to use the code tags ( </> )  it makes posts a lot easier to use for error messages and sketches.

It may not be the answer you were looking for but its the one I am giving based on either experience, educated guess, google or the fact that you gave nothing to go with in the first place so I used my wonky crystal ball.

b_dunn

Ballscrewbob

1.)  I tried plain reset and Master Reset with neither one working.
2.)  I went through nearly all of the IDE versions to see if one worked - none of them allowed me to upload to the board.  I happened to have revision 1.8.2 loaded the time I took the information for my post.  I am using 1.8.3 now and normally since it came out.
3.)  I tried Com3, Com5, Com13 and Com15 -  none of these allowed me to upload to the board.
4.)  I found each time I downloaded a new IDE a request came for me to O.K. "download srl driver" - I did O.K. download of the srl driver on previous days. Today, I read that was a separate company and did not O.K. download of the srl driver - neither way permitted me to upload the compiled Hex code to the board.
5.)  I visually examined the Hex file ASCII code within the Blink.ino.hex file - the ASCII hex code looks normal - it must be a good compilation.
6.)  I watched the Device Manager page while my upload was being held up by the
Code: [Select]
waiting for device...
error and noticed my upload threw a Windows 45 error in yellow on the active USB port Com15 - this indicates the port driver was lost at the time I was waiting on device - why is this occurring?.  This might explain the trouble I am having. When the IDE code compilation finally comes to an end with an
Code: [Select]
ERROR: Timed out waiting for Arduino 101 on COM15  The Windows 45 error is gone and the active port shows again in Device Manager as Com15 as the failed attempt at uploading ends.

Here is the code a short time before and during this particular time:

Code: [Select]
\arduino_build_721058/Blink.ino.hex"
Sketch uses 48712 bytes (31%) of program storage space. Maximum is 155648 bytes.
Forcing reset using 1200bps open/close on port COM15
C:\Users\Bill\AppData\Local\Arduino15\packages\Intel\tools\arduino101load\2.0.1/arduino101load -dfu=C:\Users\Bill\AppData\Local\Arduino15\packages\arduino\tools\dfu-util\0.9.0-arduino1 -bin=C:\Users\Bill\AppData\Local\Temp\arduino_build_721058/Blink.ino.bin -port=COM15 -v -ble_fw_str="ATP1BLE00R-1631C4439" -ble_fw_pos=169984 -rtos_fw_str="" -rtos_fw_pos=0 -core=2.0.0
arduino101load 2.0.1 - compiled with go1.7.5
Starting download script...
Serial Port: COM15
BIN FILE C:\Users\Bill\AppData\Local\Temp\arduino_build_721058/Blink.ino.bin
Waiting for device...
Waiting for device...
Waiting for device...
Waiting for device...
Waiting for device...
Flashing is taking longer than expected
Try pressing MASTER_RESET button
Waiting for device...
Waiting for device...
Waiting for device...
Waiting for device...
Waiting for device...
ERROR: Timed out waiting for Arduino 101 on COM15
ERROR: Timed out waiting for Arduino 101 on COM15





ballscrewbob

OK first off you will be fine with the .SRL drivers.
I would let them install as they should also be the latest ones.
AFAIK they are properly signed too.

I can only use my 101 with the desktop IDE and not at all with the ONLINE editor.

Have become so accustomed to just hitting reset at the very first "Waiting for device..." rather than the lottery of will it wont it.

Adding an attachment to this post too that I developed because I have so many different boards and change IDE's to test etc etc

Maybe it might help ?

It may not be the answer you were looking for but its the one I am giving based on either experience, educated guess, google or the fact that you gave nothing to go with in the first place so I used my wonky crystal ball.

redpillbug

When you load the code, it will show
 Flashing is taking longer than expected
Try pressing MASTER_RESET button
at this time hold the master reset button or press and release it continuously then it will work.
It worked to me. Hope if this helps you guys. :)

Mistral101

I had the same issue crop up today out of the blue.  I changed nothing on my PC or otherwise - I just started getting the error message "flashing is taking longer than expected try pressing master_reset button"

I updated the firmware per ballscrewbob's instructions on the following post:  http://forum.arduino.cc/index.php?topic=468349.0

I also removed and reinstalled the Arduino plugin. 

The online editor now works. 

In 25 years of working with PCs, I've seen time and again how $#!+ happens for no apparent reasons.  Frustrating for sure. 

ballscrewbob - thanks for your help here - this is the second problem you've helped me resolve.  Appreciate your contributions to the forum. 

ballscrewbob

@ Mistral101

People here help me as much if not more than I help others.
Just giving back to the community but thanks for boosting my confidence in what I try to do.
Just remember I can also be wroung ;)



It may not be the answer you were looking for but its the one I am giving based on either experience, educated guess, google or the fact that you gave nothing to go with in the first place so I used my wonky crystal ball.

thedemoriliza

my 101 didnt work on my mac. installing the 'intel curie boards ' version 1.0.5 in the boards manager got it going

DrGee

#52
Feb 23, 2018, 06:22 pm Last Edit: Feb 23, 2018, 06:27 pm by DrGee
At wits end!!

Most all of b_dunn's situation started happening here as well.

Win 7 64 bit.
Arduino IDE 1.8.5
Real-Time scanning in antivirus off.
Using a USB2 port (many ports tried)

Long log attached but it is the same time-out problem. Can't burn bootloader. Can't load program.

Intel Curie boards 2.02 installed (have tried many other earlier versions)


I have successfully used 2 other 101's in the past. This board is new as I wanted a spare since they are end of life. The point is that this is a relatively new issue as I have programmed 101 boards many times using my current equipment.

Thinking it was a bricked board I loaded a new version of the IDE, again 1.8.5, on a different machine (this laptop has never had the IDE). It worked! I was able to burn a Firmware update and run blink several times without problem. Note the laptop is a 32 bit version of windows 7 (starter) NOT the 64 bit Win 7 as described above. The point is that the board is not bricked.

I have read all of the message in this thread and all of the ones in the sticky troubleshooting thread.

I have tried all of the relevant fixes as far as I can tell. Even a few others. I am an old-timer with these windows problems and sooner or later, I figure it out...but not this time and it is driving me nuts.

I am focusing now on this phenomenon:

When I run dpinst-amd64.exe (in 2.02 drivers)  I can force a reload of the 3 relevant drivers:

The Device Driver Installation pops up (in a window that I can't resize or copy and past from) and it shows three drivers "ready to use":
Intel Corp USB (10/13/2015 1.1.0.0)
libusb 1.0 (WinUSB) libusb (WinUSB) devices (10/13/2015)
http//www.intel.com (USBser) Ports (10/13/2015 5.1.2600.0)

Then, when I plug the board in (with the IDE loaded)
I always get a fail on the DFU driver - ALWAYS - unplugged (see attached jpg)
If the serial monitor driver has to also load (depends on restarting the computer) it will successfully load), but the DFU driver always fails.


What the %$@# is going on - can anyone make a suggestion???



ballscrewbob

@DrGee

If you have any antivirus or similar security try installing the drivers with it turned OFF
Also try that method to see if you can do an upload.

DO stick with the USB 2.0 ports as they are more reliable.
Try other USB cables as they can go bad at any time.

There was a driver from Intel themselves that I found useful on occasion.
But DO NOT use the firmware from that page !




It may not be the answer you were looking for but its the one I am giving based on either experience, educated guess, google or the fact that you gave nothing to go with in the first place so I used my wonky crystal ball.

DrGee

@DrGee

If you have any antivirus or similar security try installing the drivers with it turned OFF
Also try that method to see if you can do an upload.

DO stick with the USB 2.0 ports as they are more reliable.
Try other USB cables as they can go bad at any time.

There was a driver from Intel themselves that I found useful on occasion.
But DO NOT use the firmware from that page !


Thanks for the thought Bob, I appreciate any help at all. Alas, no joy.

The AV is as off as it gets.

Tried different cables long ago :)

The archaic tool chain that you pointed to is not likely of much help and I'm not sure that it has anything in the way of drivers that would be relevant. In this regard, however, I also use this machine to program a D2000 board (Intel Quark) using Intel System Studio which is a variety of Eclipse. It, apparently has the ability to use the 101, but I have never done that. Even if it would work, it would be a hollow victory. Getting it to work with the Arduino IDE is the goal here. Since I know the board does work on a 32 but 'fresh' Win 7 laptop, the goal is to get it to work with a 64 bit Win 7 system - the same one that I have used dozens of times with these boards - as well as a PIC programmer, various other Arduinos, the D2000 and Atmel boards (Atmel Studio), and Cypress PsOC creator.

Something has changed and I am suspecting dpinst-amd64 or the dlls associated with it - or maybe it is just something I am not thinking about or don't know enough to understand (likely).

Frustrating as all get-out.

I wish facchinm would respond - but the board is end of life.

ballscrewbob

#55
Feb 24, 2018, 03:59 pm Last Edit: Feb 24, 2018, 04:09 pm by ballscrewbob
My 101 runs on x64 from win 7 upwards so its not that aspect.
Just so you dont go chasing a false lead.

X64 pro Win 7 is my goto box with FULL admin rights not just user admin rights.
Also have Driver enforcement turned off as I play quite a lot with so many Arduinos.

As another test you could enable the HIDDEN admin account log into it and also turn off driver enforcement to see if that fixes it.

Dont use the hidden admin account for anything other than testing BTW.

Yes facchinm is the man for this type of issue but I think he is more Linux ?
It may not be the answer you were looking for but its the one I am giving based on either experience, educated guess, google or the fact that you gave nothing to go with in the first place so I used my wonky crystal ball.

DrGee

My 101 runs on x64 from win 7 upwards so its not that aspect.
Just so you dont go chasing a false lead.
Mine used to as well :(

DrGee

No progress on this device not responding issue (see my post #52 - and others).

The most compelling explanation appears to revolve around the failure of the 1200 b port reset touch.

Because I have used this machine with 2.02 at least back in June of 2017 and reading facchinm 's post here https://github.com/arduino/ArduinoCore-arc32/issues/526 (April 18, 2017), I do not believe it is a firmware issue.

I think it is likely a Win 7 setting issue - but I don't really know. A lot has changed on this machine in the last year, but nothing that I can point to as suspect.

*sigh*

Go Up