Increase wait for upload port timeout to 5s on all platforms #4515

sandeepmistry · 2016-02-01T20:55:55Z

OS X 10.11 seems to be slower (with Arduino Zero native port), increasing timeout to 5s on all platforms to keep things simple.

This helps address arduino/ArduinoCore-samd#62.

Breidenbach · 2016-02-02T00:08:11Z

Tested on Mac OS 10.11.3 (El Capitan)

Cannot upload to genuine Arduino Uno which does work with windows XL and which did work before El Capitan.
Bluetooth keyboard and mouse disabled.
Arduino resets, then continues running prior sketch.
No diagnostics given by IDE.
Tried again, with no visible response by Arduino.

Hal Breidenbach
(I’ll be happy to get diagnostics if you tell me how)

On Feb 1, 2016, at 4:39 PM, ArduinoBot [email protected] wrote:

Build successful. Please test this code using one of the following:
http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-4515-BUILD-497-linux32.tar.xz http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-4515-BUILD-497-linux32.tar.xz
http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-4515-BUILD-497-linux64.tar.xz http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-4515-BUILD-497-linux64.tar.xz
http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-4515-BUILD-497-windows.zip http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-4515-BUILD-497-windows.zip
http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-4515-BUILD-497-macosx.zip http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-4515-BUILD-497-macosx.zip
—
Reply to this email directly or view it on GitHub #4515 (comment).

sandeepmistry · 2016-02-02T19:36:17Z

@Breidenbach thanks for taking the time to try out this patch and provide feedback.

I would not expect any difference in behaviour compared to the latest hourly build with an Arduino Uno board.

The waitForUploadPort method which was changed is only called for boards that have <board>.upload.wait_for_upload_port=true in boards.txt (typically only boards with USB CDC). This is not the case for the Uno board.

I tried it out with an Uno on my OS X 10.11.3 laptop and no issues:

Communication Device:

  Product ID:   0x0043
  Vendor ID:    0x2341
  Version:  0.01
  Serial Number:    74132343430351E03152
  Speed:    Up to 12 Mb/sec
  Manufacturer: Arduino (www.arduino.cc)
  Location ID:  0x14200000 / 17
  Current Available (mA):   1000
  Current Required (mA):    100
  Extra Operating Current (mA): 0

sandeepmistry · 2016-02-29T18:49:22Z

@tigoe if you have some time, could you please try out the latest build with a SAMD based board (on native USB) with and without a USB hub on your Mac.

I noticed OS X would report "Resource Busy" if a /dev/cu.usbmodem* device was opened quickly after the IDE discovered it. The latest commit adds an OS X specific delay.

tigoe · 2016-02-29T20:02:25Z

Just the latest nightly? Will try next time I hit a network with my laptop

Tom Igoe

sent on the go. please forgive any terseness or typos
On Feb 29, 2016 1:49 PM, "Sandeep Mistry" [email protected] wrote:

@tigoe https://github.com/tigoe if you have some time, could you please
try out the latest build with a SAMD based board (on native USB) with and
without a USB hub on your Mac.

I noticed OS X would report "Resource Busy" if a /dev/cu.usbmodem* device
was opened quickly after the IDE discovered it. The latest commit adds an
OS X specific delay.

—
Reply to this email directly or view it on GitHub
#4515 (comment).

Breidenbach · 2016-02-29T20:03:09Z

Tried 2 times with blink to Leonardo, 1 time with another sketch using serial output, none ran, but none disabled bluetooth keyboard or mouse. Did get attached report but about excessive wake-ups.

Hal

On Feb 29, 2016, at 1:49 PM, Sandeep Mistry [email protected] wrote:

@tigoe https://github.com/tigoe if you have some time, could you please try out the latest build with a SAMD based board (on native USB) with and without a USB hub on your Mac.

I noticed OS X would report "Resource Busy" if a /dev/cu.usbmodem* device was opened quickly after the IDE discovered it. The latest commit adds an OS X specific delay.

—
Reply to this email directly or view it on GitHub #4515 (comment).

sandeepmistry · 2016-02-29T20:22:07Z

@tigoe sorry, this build specifically: http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-4515-BUILD-515-macosx.zip (from #4515 (comment))

The changes are not in master yet.

sandeepmistry · 2016-02-29T20:29:37Z

@Breidenbach thanks for trying. I have no issues loading the blink example onto my Leonardo.

How does the behaviour you are seeing compare to the latest hourly build?

Breidenbach · 2016-02-29T22:55:35Z

The same. I haven’t tried the hourly builds for a while, since they wiped out bluetooth to the keyboard and mouse and I had to keep rebooting to get them back. I notice that the device is listed at the bottom of the screen, and the compile messages look good.

As I’m writing this, I see that the device is listed as bluetooth. (screen shot 1) I ran it again with the leonardo device (screen shot 2) and lost the keyboard and mouse.

On the second try the L light pulsed 14 times, the the RX light pulsed twice, then nothing.

Running Yosemite

Hal

On Feb 29, 2016, at 3:29 PM, Sandeep Mistry [email protected] wrote:

@Breidenbach https://github.com/Breidenbach thanks for trying. I have no issues loading the blink example onto my Leonardo.

How does the behaviour you are seeing compare to the latest hourly build https://www.arduino.cc/en/Main/Software#hourly?

—
Reply to this email directly or view it on GitHub #4515 (comment).

tigoe · 2016-03-01T00:39:58Z

@sandeepmistry, I tried with a MKR1000 and it worked great, uploaded perfectly every time. Even when the serial monitor was open. I also tried unplugging the board with the serial monitor open then plugging it back in and uploading, and it worked perfectly.

Tried the same thing with a 101 board, and the upload worked fine there as well. If I had the serial monitor was open and I unplugged the board, I got "board is not available" after a few seconds, but upload continues to work fine.

I also have a Feather M0 on me, and wanted to test with that, since I had a terrible time with the Feathers yesterday in a workshop. Sometimes I had to hit upload ten times, using 1.6.7. I don't know what's different about their bootloader from the standard M0 bootloader, but there is definitely a difference. But when I opened the PR4515 build 515 version, the Feather board definitions disappeared, and I couldn't install them via the boards manager. As a matter of fact, all my third party boards had disappeared. I didn't test too far on that, though. It seems like it's only looking at the arduino-beta folder in Arduino15/packages, and none of the other folders in packages/. Is that the case?

I have no hub with me right now, sorry, and no boards other than the three I mentioned.

sandeepmistry · 2016-03-01T14:11:15Z

@Breidenbach thanks for the info. I suggest you create a forum post about your issues. As they are outside the scope of this pull request. (Btw, when you reply via email Github does not show any of your attachments).

sandeepmistry · 2016-03-01T14:15:50Z

@tigoe great, thanks for trying! We'll hold off merging this until we get feedback on behaviour with a USB hub. Both with and without a hub, are reliable for me.

I'll look into why the other board manager boards aren't visible with this IDE build. It's based on an hourly build from yesterday. I'm curious to see if it improves sketch uploads to the Feather M0 on a Mac.

sandeepmistry · 2016-03-01T21:21:29Z

@tigoe I had no issues with seeing the Feather M0 board when adding via the board manager and this IDE build:

Could you please try the latest hourly build, to see if it has the same issue.

tigoe · 2016-03-03T05:43:24Z

Once i eliminated the arduino-beta folder I was able to see it fine as well.

With the Feather M0, I’m still getting

No device found on cu.usbmodem1421

about every other upload. FWIW, I’m also getting this:

Warning: platform.txt from core 'Adafruit SAMD Boards' contains deprecated recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} {compiler.ar.extra_flags} "{build.path}/{archive_file}" "{object_file}", automatically converted to recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} {compiler.ar.extra_flags} "{archive_file_path}" "{object_file}". Consider upgrading this core.

Could that be related to the upload issue? Maybe there’s something in their version of the M0 board definition that needs updating?

On Mar 1, 2016, at 10:21 PM, Sandeep Mistry [email protected] wrote:

@tigoe https://github.com/tigoe I had no issues with seeing the Feather M0 board when adding via the board manager and this IDE build:

https://cloud.githubusercontent.com/assets/1163840/13442263/527416f6-dfc9-11e5-8e42-44104fb25dce.png
Could you please try the latest hourly build https://www.arduino.cc/en/Main/Software#hourly, to see if it has the same issue.

—
Reply to this email directly or view it on GitHub #4515 (comment).

sandeepmistry · 2016-03-03T14:17:23Z

@tigoe

Could that be related to the upload issue?

The warning is unrelated to the uploading in this care.

Maybe there’s something in their version of the M0 board definition that needs updating?

I suspect there is something up with the bootloader, the Zero/MKR1000 bootloader seems slower than the Leonardo's for USB CDC to initialize. The Adafruit bootloader appears to be even more slower at this.

In my latest change, I added a 250ms delay after the /dev/cu.usbmodem1421 device is detected by the IDE, so that we don't launch the bossac upload tool immediately.

The "No device found on cu.usbmodem1421" error message from bossac is a bit misleading, as it means either /dev/cu.usbmodem1421 does not exist, or there was a error opening the device. In this case, "Resource Busy" because the USB device isn't quite setup, even though OS X has /dev/cu.usbmodem1421 available on the file system.

I'm not too keen on bumping the delay now, having the IDE try to open the port until it is non-busy might be a better option.

sandeepmistry · 2016-03-09T17:40:14Z

@facchinm @cmaglie please review.

This resolves sketch upload issues on the MKR1000 and OS X for myself and @tigoe, both with and without a USB hub.

facchinm · 2016-03-10T08:40:49Z

Hi @sandeepmistry ,
I'd remove the if (OSUtils.isMacOS()) part when reopening the port since a small delay is useful on all platform (included Linux).
Or, alternatively, if you could test the behaviour using #4482 it would be great, since in this commit there is a similar delay added for all platform

facchinm · 2016-03-10T08:41:44Z

The second part, instead, looks really good 😄

OS X 10.11 seems to be slower, increasing timeout to 5s on all platforms to keep things simple.

…source busy" errors on open

sandeepmistry · 2016-03-10T14:48:13Z

@facchinm thanks for reviewing!

I've applied your suggestion from #4515 (comment) in sandeepmistry@7cb1399.

Unfortunately #4482 still fails every second sketch upload with the MKR1000 + USB, with the following bossac error:

An error occurred while uploading the sketch
No device found on cu.usbmodem14221

ArduinoBot · 2016-03-10T15:20:43Z

✅ Build completed.

Please test this code using one of the following:

⬇️ http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-4515-BUILD-522-linux32.tar.xz
⬇️ http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-4515-BUILD-522-linux64.tar.xz
⬇️ http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-4515-BUILD-522-windows.zip
⬇️ http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-4515-BUILD-522-macosx.zip
⬇️ http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-4515-BUILD-522-linuxarm.tar.xz

ℹ️ The linuxarm build is still experimental and may not be always available.

don · 2016-03-23T20:34:05Z

This fixes timeout problems for me on OS X 10.10.5 with MKR-1000.

sandeepmistry mentioned this pull request Feb 1, 2016

1200bps reset unreliable arduino/ArduinoCore-samd#62

Closed

sandeepmistry force-pushed the wait-for-upload-port-timeout-bump branch from e86fd39 to 7ed0cb1 Compare February 29, 2016 18:02

sandeepmistry added 3 commits March 10, 2016 09:37

Increase wait for upload port timeout to 5s on all platforms

de41265

OS X 10.11 seems to be slower, increasing timeout to 5s on all platforms to keep things simple.

Add OS X specific delay after waiting for upload port, to prevent "Re…

7a535d9

…source busy" errors on open

Apply extra 250ms after waitForUploadPort to all platforms

7cb1399

sandeepmistry force-pushed the wait-for-upload-port-timeout-bump branch from 7ed0cb1 to 7cb1399 Compare March 10, 2016 14:44

facchinm merged commit 629509f into arduino:master Apr 1, 2016

cmaglie added this to the Release 1.6.9 milestone Apr 5, 2016

sandeepmistry deleted the wait-for-upload-port-timeout-bump branch July 18, 2016 18:06

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Increase wait for upload port timeout to 5s on all platforms #4515

Increase wait for upload port timeout to 5s on all platforms #4515

sandeepmistry commented Feb 1, 2016

Breidenbach commented Feb 2, 2016

sandeepmistry commented Feb 2, 2016

sandeepmistry commented Feb 29, 2016

tigoe commented Feb 29, 2016

Breidenbach commented Feb 29, 2016

sandeepmistry commented Feb 29, 2016

sandeepmistry commented Feb 29, 2016

Breidenbach commented Feb 29, 2016

tigoe commented Mar 1, 2016

sandeepmistry commented Mar 1, 2016

sandeepmistry commented Mar 1, 2016

sandeepmistry commented Mar 1, 2016

tigoe commented Mar 3, 2016

sandeepmistry commented Mar 3, 2016

sandeepmistry commented Mar 9, 2016

facchinm commented Mar 10, 2016

facchinm commented Mar 10, 2016

sandeepmistry commented Mar 10, 2016

ArduinoBot commented Mar 10, 2016

don commented Mar 23, 2016

Increase wait for upload port timeout to 5s on all platforms #4515

Increase wait for upload port timeout to 5s on all platforms #4515

Conversation

sandeepmistry commented Feb 1, 2016

Breidenbach commented Feb 2, 2016

sandeepmistry commented Feb 2, 2016

sandeepmistry commented Feb 29, 2016

tigoe commented Feb 29, 2016

Tom Igoe

Breidenbach commented Feb 29, 2016

sandeepmistry commented Feb 29, 2016

sandeepmistry commented Feb 29, 2016

Breidenbach commented Feb 29, 2016

tigoe commented Mar 1, 2016

sandeepmistry commented Mar 1, 2016

sandeepmistry commented Mar 1, 2016

sandeepmistry commented Mar 1, 2016

tigoe commented Mar 3, 2016

sandeepmistry commented Mar 3, 2016

sandeepmistry commented Mar 9, 2016

facchinm commented Mar 10, 2016

facchinm commented Mar 10, 2016

sandeepmistry commented Mar 10, 2016

ArduinoBot commented Mar 10, 2016

don commented Mar 23, 2016