USB Native Port Not Detected After Burn Bootloader

[rocketscream]

Using the Arduino Zero's EDBG to burn the native USB bootloader onto the ATSAMD21GA chip on the same Zero board resulted in the native USB port not detected on both Windows 10 & Ubuntu 14.04. The native USB port will no longer be detected after that. If the we then upload the Blink example through the USB Programming port of the same board, the LED will blink at a 0.5 Hz rate instead of the default 1 Hz. Arduino IDE 1.6.6, 1.6.7, 1.6.8 with SAMD 1.6.4, 1.65 is used. Hourly built IDE (21 April 2016 2:34:34 GMT) with the SAMD hourly built was also tested but all the combination resulted in same exact behavior.

Also verified on a custom board using SAM-ICE and resulted in same behavior.

[cmaglie]

@rocketscream
I confirm this bug, it is due to this change:
#124
d7a41f5

there is a bug in OpenOCD that erase the NVM User Row (a sort of fuses in the samd21) when trying to set bootloader protection to 8192. This is a really weird bug and the worst thing is that, right now, this is not recoverable using OpenOCD itself, you need Atmel Studio.

We are working on a way to restore the NVM User Row from the Arduino IDE, we'll keep you posted.

[rocketscream]

An important point to note, the native USB port first became brick when I try to load an example sketch from Adafruit ILI9341 library. The only thing I remember my setup that was different is that SAMD core was 1.6.5. So, it affects the upload sketch process as well?

I did try fixing it using ASF but didn't touch the NVM ROW fuse. Instead was thinking that it was an issue with NVM CTRL BOOT PRO.

Thanks for checking this out.

[ladyada]

@cmaglie ??? i used OpenOCD to burn bootloader with protection (w/a raspiberry pi native GPIO) and it works great, is it related to EDBG's implementation on OpenOCD ???

[cmaglie]

@ladyada
that's really weird, after reading your message I tried again and I failed to reproduce the error.
Only after a good amount of tests, finally, I can reproduce this bug reliably, the steps are:

1. Burn bootloader (with protection enable)
2. Upload blink
3. Burn bootloader again (with protection enable)
4. Upload blink
5. ERROR: observe blinking at 0.5 sec rate instead of 1.0 sec

This explains also why it passed my tests when I merged d7a41f5: it needs two "burn bootloader+upload" actions in a row to actually show the bug. I don't know if this is a bug in OpenOCD or in the EDBG firmware.

@rocketscream
Now a good news, it's easy to "un-brick" the Zero Board via Arduino IDE, just follow these steps:

1. upload this sketch from the programming port: https://gist.github.com/cmaglie/c411621b8d49494faeb7869ad59aa6b6
2. let it run for a couple of seconds (even if one second should be sufficient)
3. power cycle the board (you need to completely power off the board to get the new settings)
4. upload blink

The sketch linked above resets the "fuses" of the SAMD21 to the default value and should fix the problem.

[rocketscream]

@cmaglie
Thank you very much. That fixes my Arduino Zero. The USB native port came back alive now. Blink also runs at the correct rate.

The WDT has been disabled along with other few fuse settings. I will take a look and compare closely.

Now I have to figure out how to fix boards without the EDBG interface. If I were to use the Atmel-ICE on ASF and burn the exact same fuse settings, would that work?

[cmaglie]

Yes that should work

[rocketscream]

@cmaglie Does the USER_WORD_0 & USER_WORD_1 (these are the new_fusebits register) must posses the value 0xD9FEC7FF & 0xFFFFFE5D (I know this is Atmel default values) as in your sketch (also verified from ASF)? It does not seem to be able to write to those values from the ASF programming device interface. The few bits that are different belongs to factory programmed values that are marked as "reserved".

But, it worked even with those few different bits setting. Thank you for the quick resolutions.

[sandeepmistry]

@rocketscream

Does the USER_WORD_0 & USER_WORD_1 (these are the new_fusebits register) must posses the value 0xD9FEC7FF & 0xFFFFFE5D (I know this is Atmel default values) as in your sketch (also verified from ASF)?

As far as we know yes, although we haven't experimented too much. We did notice the board would start to heat up with other values.

It does not seem to be able to write to those values from the ASF programming device interface. The few bits that are different belongs to factory programmed values that are marked as "reserved".

I was seeing that as well.

I'm going to close this for now, as 153d993 is in the 1.6.6 release and prevents this issue.

[selvamaniraj]

Hey guys I have a problem in enabling the usb port. I am using atmel studio to flash the ATSAMD21G18 and while doing that its the LED blinks but the USB port is not enabled so I am following your procedure which is -

1. upload this sketch from the programming port:https://gist.github.com/cmaglie/c411621b8d49494faeb7869ad59aa6b6
2. let it run for a couple of seconds (even if one second should be sufficient)
3. power cycle the board (you need to completely power off the board to get the new settings)
4. upload blink
   But the procedure shows error and I have attached the screenshot of my issue in this post. Can someone help me please and thanks in advance.

[sms2000]

Hi
I understand I need a programming port to unbrick Zero,

But I have clone Zero with native port only. It was bricked with FreeRTOS for Zero "serialPrintInThread" example.
Do I need a programmer to revive the clone-Zero?

[ladyada]

@sms2000 yep, a jlink, Atmel ICE or similar can do it

[sms2000]

Tnx

The one more question. I have a ULINK2 programmer. Could it be used? openocd doesn't seems to like it.

BTW, I unbricked the clone. More than once. The idea is to press reset and upload and repeat the process many times till succeeded.