Fail to upload to MKR1000 on Windows 7

[hanabanana]

The MKR1000 board I've been working with for months failed upload consistently on several Windows 7 computers(all have the exact same image and configuration) with the following error,

Sketch uses 8944 bytes (3%) of program storage space. Maximum is 262144 bytes.
Forcing reset using 1200bps open/close on port COM7
PORTS {COM1, COM3, COM7, } / {COM1, COM3, } => {}
PORTS {COM1, COM3, } / {COM1, COM3, } => {}
PORTS {COM1, COM3, } / {COM1, COM3, } => {}
PORTS {COM1, COM3, } / {COM1, COM3, COM12, } => {COM12, }
Found upload port: COM12
C:\Temp\arduino-1.8.0\portable\packages\arduino\tools\bossac\1.7.0/bossac.exe -i -d --port=COM12 -U true -i -e -w -v C:\Users\msguest\AppData\Local\Temp\arduino_build_272849/sketch_jan04a.ino.bin -R 
Set binary mode
readWord(addr=0)=0x20007ffc
readWord(addr=0xe000ed00)=0x410cc601
readWord(addr=0x41002018)=0x10010305
version()=v2.0 [Arduino:XYZ] Nov 24 2015 11:34:08
chipId=0x10010005
Connected at 921600 baud
readWord(addr=0)=0x20007ffc
readWord(addr=0xe000ed00)=0x410cc601
readWord(addr=0x41002018)=0x10010305
Atmel SMART device 0x10010005 found
write(addr=0x20004000,size=0x34)
writeWord(addr=0x20004030,value=0x10)
writeWord(addr=0x20004020,value=0x20008000)
Device       : ATSAMD21G18A
readWord(addr=0)=0x20007ffc
readWord(addr=0xe000ed00)=0x410cc601
readWord(addr=0x41002018)=0x10010305
Chip ID      : 10010005
version()=v2.0 [Arduino:XYZ] Nov 24 2015 11:34:08
Version      : v2.0 [Arduino:XYZ] Nov 24 2015 11:34:08
Address      : 8192
Pages        : 3968
Page Size    : 64 bytes
Total Size   : 248KB
Planes       : 1
Lock Regions : 16
Locked       : readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
readWord(addr=0x41004020)=0xffff
none
readWord(addr=0x41004018)=0
Security     : false
Boot Flash   : true
readWord(addr=0x40000834)=0x7000a
BOD          : true
readWord(addr=0x40000834)=0x7000a
BOR          : true
Arduino      : FAST_CHIP_ERASE
Arduino      : FAST_MULTI_PAGE_WRITE
Arduino      : CAN_CHECKSUM_MEMORY_BUFFER
Erase flash
chipErase(addr=0x2000)
done in 0.802 seconds

Write 9200 bytes to flash (144 pages)
write(addr=0x20005000,size=0x1000)
writeBuffer(scr_addr=0x20005000, dst_addr=0x2000, size=0x1000)

[=============                 ] 44% (64/144 pages)write(addr=0x20005000,size=0x1000)
writeBuffer(scr_addr=0x20005000, dst_addr=0x3000, size=0x1000)

SAM-BA operation failed
An error occurred while uploading the sketch

[==========================    ] 88% (128/144 pages)write(addr=0x20005000,size=0x400)
writeBuffer(scr_addr=0x20005000, dst_addr=0x4000, size=0x400)

[==============================] 100% (144/144 pages)
done in 0.065 seconds

Verify 9200 bytes of flash with checksum.
checksumBuffer(start_addr=0x2000, size=0x1000) = 7cfc
checksumBuffer(start_addr=0x3000, size=0x1000) = 5acd
checksumBuffer(start_addr=0x4000, size=0x3f0) = 3b88
Verify successful
done in 0.013 seconds
CPU reset.
readWord(addr=0)=0x20007ffc
readWord(addr=0xe000ed00)=0x410cc601
readWord(addr=0x41002018)=0x10010305
writeWord(addr=0xe000ed0c,value=0x5fa0004)

What I have tried:

1. Tried the same board on my own Win7 PC before and after it failed on those machines --> worked fine
2. Tried other MKR1000 boards on those machines --> no luck
3. Tried changing cables --> no luck
4. Tried both USB2.0 and USB3.0 ports --> no luck
5. Tried same board on a Win10, a Mac(10.11) and a Linux(Debian 8.3)--> worked fine
6. Tried both IDE 1.6.7 SAMD version 1.6.8 and IDE 1.8.0 SAMD version 1.6.11 --> no luck
7. Tried Due board on those machines --> worked fine(Due and MKR1000 seemed to use the same bossac.exe)

What exactly can cause an error of "SAM-BA operation failed"? Without more info about that, I couldn't figure out what's so special about those machines that make them "incompatible" with MKR1000 driver or uploader.

[facchinm]

Hi @hanabanana ,
it really looks like a problem with the Win7 PCs themselves. Maybe they have something installed which tries to open the serial port as soon as it appears (incidentally, in the middle of the upload) ? On Ubuntu, this is normally caused by modemmanager, a daemon which tries to open any serial port looking for a 56k modem. Maybe on that PCs something similar is happening?

[dlabun]

The baud rate looks abnormally fast, could be part of your issue.

[facchinm]

@dlabun it can't be the problem, bossac tries some baud rates starting from the fast ones, and of course the MKR1000 acknowledges since it's not a real serial but a CDC port (so all baud rates are supported)

[hanabanana]

@facchinm Having checked with our IT, there isn't any such service or application that we can think of on those machines. They should have standard build with minimal software installed. We can double-check this. We can also try to start them with the bare-minimum route and see if anything changes. If you have any other ideas in the meantime, let me know.

[hanabanana]

We did more digging and might have found out the answer. Our IT department overwrote the factory Windows 10 image that comes with those M900 machines with a custom Windows 7 image. When we reverted back the image to the factory default Windows 10, the code uploaded fine. But with the Windows7 , we tried the minimal startup and chipset/USB driver update, which all failed. Our guess is this machine model probably is only fully compatible or tested with Windows10 drivers. Most Arduino users probably won't run into this unless they have done something similar.

[kiptonk]

I've seen this same behavior. SAM-BA operation failed under Win7 but no problems under Win10. The fix was to disable USB3 under Win7. I uninstalled the Intel USB3 driver package and disabled USB xHCI in the BIOS. Everything then started working under Win7. Note that using a 4-pin black USB2 port will still exhibit the problem until USB3 is disabled - surprising behavior. I suspect there is some issue with bossac and USB3 under Win7 but I haven't done any more digging. I've also read a workaround is to install a USB2 hub between the PC and the device.

[saviojdsouza]

I was alos getting the same error ( SAM BA op failed).i tired part of the above kiptonk mentioned. Only disabled Intel USB3 drivers. I then used the USB2 ports and the upload worked on my win7 laptop. Have to mentioned did this test for a small blink code only. Thanks all for sharing.

[jackrubin]

I also received the "SAM BA operation failed" error while uploading sketches to my MKRZERO, though the upload continues past the error, the code loads and verifies, and programs run successfully. The system used is a Win 7 Enterprise installation. When I moved the same code and MKR board to a Win 10 laptop, the code compiled, loaded and ran without error.

Disabling the USB3 ports on my Win 7 system is not an option, but by interposing a USB2 hub between the Win7 box and the MKRZERO, I was able to achieve error-free operation on my Win7 box as well.

This is a clear bug but the easy work-around has reduced it to an annoyance.

[kiptonk]

This issue persists for me under Win7 and the workaround of disabling xHCI/USB3 no longer applies. The only workaround now is a hardware USB2 hub between the Win7 PC and the SAMD. I suspect the incompatibility in the Intel xHCI/USB3 driver has since been rolled into a Windows Update. As a sidenote, I see similar timeout behavior with only two other devices: an Arduino Pro Micro and an older Harmony Universal Remote - neither will program successfully without a hardware USB2 hub as go-between. Not sure what these 3 devices have in common, not bossac... maybe some device-side USB driver code?

[Stan14]

This issue persists for me under Win7 and the workaround of disabling xHCI/USB3 no longer applies. The only workaround now is a hardware USB2 hub between the Win7 PC and the SAMD. I suspect the incompatibility in the Intel xHCI/USB3 driver has since been rolled into a Windows Update. As a sidenote, I see similar timeout behavior with only two other devices: an Arduino Pro Micro and an older Harmony Universal Remote - neither will program successfully without a hardware USB2 hub as go-between. Not sure what these 3 devices have in common, not bossac... maybe some device-side USB driver code?

I think I guessed why the hub-in-between helps. USB Speed. The hub slows down the transfer rate and usb connection succeeds. To verify that just run any USB benchmark program for some flash-drive connected directly and through that hub, you will se a big difference in speed.

[Stan14]

More to that:
https://forums.adafruit.com/viewtopic.php?f=57&t=167008
In brief, device publishes wring descriptor value, pretending to be USB2.0 while actually it is USB1.1.
And the port in between I used turned out to be genuine USB 1.1.