SAM-BA operation failed

I've got a brand new Arduino DUE board (R3).
First time I uploaded the basic blink program everything worked the way it should. Then I tried to upload a serial communication program and that is when I started to get the "SAM-BA operation failed" error.
Tried the blink program again and now I'm getting the error message there too.
Tried power cycling the board but with the same problem. Tried power cycling the computer as well but no luck.
Running Win7 64 bit ultimate and Arduino 1.5.2.

This is the output

Binary sketch size: 9 860 bytes (of a 524 288 byte maximum) - 1% used
Erase flash
Write 9940 bytes to flash

[                              ] 0% (0/39 pages)
[=======                       ] 25% (10/39 pages)
[===============               ] 51% (20/39 pages)
[=======================       ] 76% (30/39 pages)
[==============================] 100% (39/39 pages)
Verify 9940 bytes of flash

[                              ] 0% (0/39 pages)

SAM-BA operation failed
[=======                       ] 25% (10/39 pages)


I usually see this if I get too eager about starting the serial monitor which tries to use the USB connection and interferes with the flash operation, could something else be trying to use the USB port? Have you tried another USB port? Another computer? Another cable?

Could be faulty hardware.

Hello noblepepper,

Load the serial sample using the programming port, then switch to the native port.

what do you mean with ''switch to the native port" ?
i build an ArduinoDUE based board and took off the native usb port. i can't connect to it

what do you mean with ''switch to the native port" ?
i build an ArduinoDUE based board and took off the native usb port. i can't connect to it

Hello aureliusss,

Are you experiencing USB connectivity issues in your board? If so, please, give us details. I mentioned to 'switch to the native port' as a 'if everything fails' case.
In my experience, thanks to Atmel's SAM-BA or Shumatech's BOSSA, Due's native port shouldn't have too much connectivity issues. But more than that, the Due's native port host capabilities is a big plus. Does your ArduinoDUE based board USB port can work as OTG interface? I've been waiting for years for an open source device with USB host capabilities. Thanks to its SAM3X8E, finally Arduino Due has arrived. And that's the reason I haven't migrated to other MCUs with a better performance like the SAM4E series, because of the host. In this aspect, the software effort made by Arduino-Atmel is formidable, putting the parts together. It is a daunting task (and no Linux needed!).

If your board cannot work as a host, I would highly recommend you to re-consider your design adding the native port. Regards!

i designed my board with the only programming port.

  1. failure on uploading a sketch: it always returns "No device found on COM" even with the right adjustment in the schematics: R23 = 1k and Y4 = 16MHz
  2. now i'm trying to upload my sketch with an external arduinoDUE using its "programming part". From the external arduinoDUE i connected TX, RX, Erase, Reset lines. The IDE starts to upload the sketch but then it returns "SAM-BA operation failed" before starting the flash verify routine.

now i don't know if the sketch has been uploaded or the error stops the uploading. anyone can help me?

The OP is describing problems with loading a program using the
standard Programming USB port (on his own "semi-clone" card)?

So, try loading using a "real" Due, and see if that works?

Or, is the OP using some other method of programming a Sketch?

Prerequisites would be good code in the "interface/programming" uP,
and probably good code in the "bios/boot" part of the SAM uP, right?

sorry, what is an OP?


Have you tried to install the Atmel's SAM-BA 2.12 USB driver in your board using Windows 7 (32bit)?
In the past, I got good results using it when having code 43, 31 or 10.
Here the SAM-BA drive path:

C:\Program Files (x86)\Atmel\sam-ba_2.12\drv


this drive should fix #1 problem? but how do i install it if my board is alredy seen as "arduino due programming port"

Problem #1. The SAM-BA driver should fix your "USB Device not Recognized" problem. This SAM-BA driver is for AT91SAM products.
Thus, when you have a chance, go back to your problem #1 and make a try. In the meantime, garygid is a good idea: replace your arduinoDUE based board with a second DUE
and see if your method work or not.

i already fixed the "usb device not recognised" changing the r23 value from 10k to 1k and the atmega16u2 oscillator from 12MHz to 16 MHz
(Both are reference schematics error). my problem (#1) is that the ide returns me "No device found on COM" even if the device menager recognize the arduino as arduinoDUE programming port

Could you try:

bossac.exe --port=COM1 -U true -i

to see if Bossa is recognizing your board. Remember to use your actual COM port (i used COM1 as an example).

here the path of bossac


EDIT:Sorry. I made a mistake. Use

bossac.exe --port=COM1 -U false -i

for the programming port.

yes, bossac is recognising the SAM. i receive this log:

C:\Users\HP\Desktop\arduino-1.5.2\hardware\tools>bossac.exe  --port=COM15 -U false -i
Device       : ATSAM3X8
Chip ID      : 285e0a60
Version      : v1.1 Dec 15 2010 19:25:04
Address      : 524288
Pages        : 2048
Page Size    : 256 bytes
Total Size   : 512KB
Planes       : 2
Lock Regions : 32
Locked       : none
Security     : false
Boot Flash   : false

i tried to upload the bin file through bossac, but it always returns me SAM-BA operation failed when it tries to verify the flash:

C:\Users\HP\Desktop\arduino-1.5.2\hardware\tools>bossac.exe  -p COM15 -U false -
e -w -v -b dbGlove_blue.cpp.bin -R
Erase flash
Write 28512 bytes to flash
[==============================] 100% (112/112 pages)
Verify 28512 bytes of flash
[                              ] 0% (0/112 pages)
SAM-BA operation failed

i just had the “operation failed … chip ID … not supported” error, attempting to upload with DUE and Arduino 1.8.0, which had been succeeding just fine… uploading and serial monitor on the Programming USB port.

to make a long story short, it was caused by debug code that was spewing out a rapid stream of Serial.print() statements fairly soon after reset. i did have while (! Serial); in setup(). i suspected this was the case, so i changed the debug chatter to be silent on reset and require intervention to enable debug (my code has a command interpreter in it, but a toggle switch would do). problem immediately solved.

even with the “high chatter” sketch installed, i managed to get upload to work by pressing reset right before upload. took a number of tries to get it to upload. it immediately solved the problem.