New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

USB Native Port Not Detected After Burn Bootloader #137

Closed
rocketscream opened this Issue Apr 21, 2016 · 12 comments

Comments

6 participants
@rocketscream
Copy link

rocketscream commented Apr 21, 2016

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

This comment has been minimized.

Copy link
Member

cmaglie commented Apr 21, 2016

@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

This comment has been minimized.

Copy link

rocketscream commented Apr 21, 2016

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

This comment has been minimized.

Copy link
Contributor

ladyada commented Apr 22, 2016

@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

This comment has been minimized.

Copy link
Member

cmaglie commented Apr 22, 2016

@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

This comment has been minimized.

Copy link

rocketscream commented Apr 22, 2016

@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

This comment has been minimized.

Copy link
Member

cmaglie commented Apr 22, 2016

Yes that should work

@rocketscream

This comment has been minimized.

Copy link

rocketscream commented Apr 23, 2016

@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

This comment has been minimized.

Copy link
Member

sandeepmistry commented May 27, 2016

@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.

@cmaglie cmaglie added this to the Release 1.6.6 milestone May 27, 2016

@selvamaniraj

This comment has been minimized.

Copy link

selvamaniraj commented Oct 11, 2016

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.

screenshot 2

@sms2000

This comment has been minimized.

Copy link

sms2000 commented Dec 2, 2017

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

This comment has been minimized.

Copy link
Contributor

ladyada commented Dec 2, 2017

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

@sms2000

This comment has been minimized.

Copy link

sms2000 commented Dec 3, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment