No USB to MKR1000

Development Tools IDE 1.x
1

I have an almost new MKR1000. Since I got it, it has sometimes failed to show up as a COM port in Windows or a serial port on OS X. Right now, it won't appear.

Searching the forum, I found advice to double-click the reset button. This has worked to restore connectivity a couple of times. Its not working now.

I have used an Atmel-ICE to re-flash the bootloader from the Arduino IDE and that worked for a time. Its not working now.

So, I have resorted to Atmel Studio to program the bootloader into flash. Doing this fails with the message:

Verifying Flash...Failed! address=0x0000 expected 0xfc, actual = 0xff

Reading the flash into a file shows all FFs. Which is probably what happens when you erase the chip. (Yes I tried erasing the chip and as far as I can tell from Atmel Studio, that succeeds.)

Reading the device signature and fuses works. It says the voltage is 3.2v although I can't see where .1v would make a difference and my meter says 3.28v across the MKR1000's Vcc and Gnd pins.

The fuses verify and appear to be correct although I can't find a reference to tell me exactly what they should be.

I suppose that the MKR1000 could be failing as it has behaved erratically since I got it. But, if there's any way to tell if the fuses are wrong or if there's anything else I can check, I'd appreciate the suggestions.

2

I probably should have added the fuse settings along with my original post. I'm putting the current settings at the bottom here side by side with a listing of "factory" settings that I found online. The settings I found are for a different board. Although it does have the same processor. There's no explanation of what the fuses do, just a listing from Atmel Studio, like the one from my board. I marked where the two differ.

I'm particularly curious about the NVMCTRL_BOOTPROT setting. As I read the data sheet, this controls the number of rows of memory reserved for the bootloader. However, the "factory" setting shows a value of 0x07. According to the datasheet pg. 389, this means 0 rows allocated for the bootloader. My board has a setting of 0x02, corresponding to 32 rows or 8192 bytes. Does the "factory" setting assume that code is loaded directly, without a bootloader?

Out of curiosity, I had looked at the bootloader size before I had this problem and it was set to 0x02. But, now I am thinking that perhaps the setting needs to be 0x07 so that the memory for the bootloader is not protected in order to burn it (and then the BOOTPROT fuse is set to 0x02 after the bootloader is programmed) Unfortunately, I need a PC to run Atmel Studio and I don't have access until Monday to try this.

Otherwise, there are other differences in the "factory" fuses and those for my board. I have not yet figured out what some of them do. So, if anyone notices any that need to be fixed and might prevent the bootloader from being uploaded, please let me know.

Here's the dump of settings from Atmel Studio:

Atmel-ICE
Debug host 127.0.0.1
Debug port 50447
Serial number J41800038005
Connection com.atmel.avrdbg.connection.cmsis-dap
Features 1
Firmware Version 1.1c
Hardware Version 0

Detected device
Device signature 0x10010305
Revision D

Datasheet information
SAMD21G18A-MU SAMD21G18A-MF SAMD21G18A-AU SAMD21G18A-AF
CPU CORTEX-M0PLUS
Flash size 256 KB
SRAM size 32 KB
VCC range 1.62 - 3.63 V 1.62 - 3.63 V 1.62 - 3.63 V 1.62 - 3.63 V
Maximum operating speed 48 MHz 48 MHz 48 MHz 48 MHz

Current fuses Factory fuses (?)

NVMCTRL_NVM_LOCK = 0x00 NVMCTRL_NVM_LOCK = 0x00
NVMCTRL_PSZ = 0x03 NVMCTRL_PSZ = 0x03
NVMCTRL_NVMP = 0x1000 NVMCTRL_NVMP = 0x1000
ADC_LINEARITY_0 = 0x08 ADC_LINEARITY_0 = 0x08
ADC_LINEARITY_1 = 0x04 ADC_LINEARITY_1 = 0x04
ADC_BIASCAL = 0x03 ADC_BIASCAL = 0x03
OSC32K_CAL = 0x37 *OSC32K_CAL = 0x3E
USB_TRANSN = 0x05 USB_TRANSN = 0x05
USB_TRANSP = 0x1D USB_TRANSP = 0x1D
USB_TRIM = 0x03 USB_TRIM = 0x03
DFLL48M_COARSE_CAL = 0x1C *DFLL48M_COARSE_CAL = 0x1E
DFLL48M_FINE_CAL = 0x200 DFLL48M_FINE_CAL = 0x200
ROOM_TEMP_VAL_INT = 0x1E ROOM_TEMP_VAL_INT = 0x1E
ROOM_TEMP_VAL_DEC = 0x06 *ROOM_TEMP_VAL_DEC = 0x00
HOT_TEMP_VAL_INT = 0x54 *HOT_TEMP_VAL_INT = 0x55
HOT_TEMP_VAL_DEC = 0x09 *HOT_TEMP_VAL_DEC = 0x00
ROOM_INT1V_VAL = 0xFF *ROOM_INT1V_VAL = 0xFB
HOT_INT1V_VAL = 0xFC *HOT_INT1V_VAL = 0xF7
ROOM_ADC_VAL = 0xB8D *ROOM_ADC_VAL = 0xB06
HOT_ADC_VAL = 0xD46 *HOT_ADC_VAL = 0xD0C

NVMCTRL_BOOTPROT = 0x02 *NVMCTRL_BOOTPROT = 0x07
NVMCTRL_EEPROM_SIZE = 0x07 NVMCTRL_EEPROM_SIZE = 0x07
BOD33USERLEVEL = 0x07 BOD33USERLEVEL = 0x07
BOD33_EN = [X]
BOD33_ACTION = 0x01 BOD33_ACTION = 0x01
WDT_ENABLE = [ ]
WDT_ALWAYSON = [ ]
WDT_PER = 0x0B WDT_PER = 0x0B
WDT_WINDOW_0 = [X]
WDT_WINDOW_1 = 0x05 WDT_WINDOW_1 = 0x05
WDT_EWOFFSET = 0x0B WDT_EWOFFSET = 0x0B
WDT_WEN = [ ]
BOD33_HYST = [ ]
NVMCTRL_REGION_LOCKS = 0xFFFF NVMCTRL_REGION_LOCKS = 0xFFFF

OTP1_WORD_0 = 0x10000300 (valid) OTP1_WORD_0 = 0x10000300 (valid)
OTP4_WORD_0 = 0x40004007 (valid) OTP4_WORD_0 = 0x40004007 (valid)
OTP4_WORD_1 = 0x71F4ADDC (valid) *OTP4_WORD_1 = 0x79F4AF9C (valid)
OTP4_WORD_2 = 0xFFFFFE00 (valid) OTP4_WORD_2 = 0xFFFFFE00 (valid)
TEMP_LOG_WORD_0 = 0xFF95461E (valid) *TEMP_LOG_WORD_0 = 0xFB05501E (valid)
TEMP_LOG_WORD_1 = 0xD46B8DFC (valid) *TEMP_LOG_WORD_1 = 0xD0CB06F7 (valid)
USER_WORD_0 = 0xD9FEC7FA (valid) *USER_WORD_0 = 0xD8E0C7FF (valid)
USER_WORD_1 = 0xFFFFFE5D (valid) USER_WORD_1 = 0xFFFFFC5D (valid)

** factory fuse information found from this webpage:

3

Ok, it is as I suspected, the 0x02 value for NVMCTRL_BOOTPROT was what was preventing the upload of the bootloader. Setting this to 0x07 means that the bootloader area is not protected. So, the bootloader can be uploaded. This time, the flash write verified instantly.

So, after the bootloader was burned, I went back and set the NVMCTRL_BOOTPROT to 0x02 to protect the newly uploaded bootloader. I'm guessing that something similar happens when you burn the bootloader with the Arduino IDE. I couldn't use the IDE because I had erased the chip and there was no bootloader to drive the USB connection.

As soon as I set the NVMCTRL_BOOTPROT fuse to 0x07, burned the bootloader, set the NVMCTRL_BOOTPROT fuse back to 0x02, I could see the MKR1000 in Device Manager and could upload Blink with the Arduino IDE.

This solved my problem with burning the bootloader using Atmel Studio.

4

Hi,

For me, this happens everytime that a sketch is uploaded, the Port dissapears.
If I need to upload a new sketch, I need to burn the bootloader using an Atmel-ICE, everything using the Arduino. After this the Port appears and is ready to upload a new sketch.

5

Thanks a lot claudeheintz. This solved my problem as well. But in my case, along with the BOOTPROT, the NVMCTRL_REGION_LOCKS was something other than 0xFFFF as well. The datasheet does mention LOCK for the NVM but there's no reference for NVMCTRL_REGION_LOCKS despite it being about the same fuse. Thanks again.