burn arduino zero's bootloader to SAMD21 with STlink_v2

hello fellow makers!

I'm trying to make a PCB with ATSAMD21G18 chip using Arduino Zero firmware.

I exposed 4 pins for STlink (SWCLK, SWDIO,3.3V,GND) and connected.

downloaded bootloader from (ArduinoCore-samd/bootloaders/zero at master · arduino/ArduinoCore-samd · GitHub) and built using make command

and used adalink for using STLink_v2 programmer (GitHub - adafruit/Adafruit_Adalink: Python wrapper for Segger's J-Link Commander & STMicro STLink V2 to flash various ARM MCUs).

The firmware seems to upload, I can see the device listed on USB:

But it is not shown as a serial device in either /dev/ or the Arduino application.

I refered to the youtube video for this method (How to burn Arduino Zero bootloader to an Atmel ATSAMD21G18-based custom dev board - YouTube).
In his video, he got some error message like "Failed to verify all files were programmed!" at the end, however his board was detected as "2341 arduino zero" in result of lsusb command, and it was in the serial port list.

I did same work, and mine was detected as "2341 arduino zero" as well. but I couldn't find it in serial port list.

I also tried rebuilding the bootloader as a UART only device and uploading that, but it still does not show as a serial device in OSX.

do you have an idea about this? '' here is my error log from OpenOCD in case it helps:

Many Thanks!
Ban

I have been researching this stuff since I am planning to do a SAMD21 board soon but have not done it yet. Anyway...

I think for the bootloader to become active when the USB is plugged in, it will need an application firmware loaded. It is sort of a chicken and egg problem, the bootloader alone is probably not looking for the USB event (open and close serial port at 1200 bps) that runs the bootloader (it is cooked into the Arduino core, so will be missing from images built from Studio, mbed, or any other toolchain). Since the bootloader does not run the USB serial looks dead, I have no idea what a good fix would be, but as a hack, I think you could force it into bootload mode with a double tap on the reset button and then the serial should show up, and the SAM-BA bootloader should be running and watching that port.

for UART this thread may help

https://forum.arduino.cc/index.php?topic=524160

Just a quick update here.. (i'm working with OP Ban on this)

On Ban's computer (Parallels Windows 10 on MBP) he gets a Code 10 (This Device Cannot Start), but the device descriptor seems to be transmitted (he gets a valid product id / vendor id, and it says something like 'Arduino Bootloader'

If I plug the same board into my computer I get a Code 43 - Invalid Configuration Descriptor. I don't get a vendor or product ID.

I managed to upload the bootloader manually through the STLink using OpenOCD without any errors (took a bit of fiddling but worked in the end). But that doesn't mean that the USB works.

We've tested this on 2 boards now with the same error, which somewhat rules out random issues in fabrication :frowning:

Thank you for the response ron!
interesting read in the other thread
Aren't all the pin assignments handled by uploading the arduino bootloader?

another note
We tried the double tap reset
Also tried 'reset run' from OpenOCD which seems to do the same thing.
Often after flashing, it's necessary to do that reset before it shows up in the system at all (but still that's when it shows up as Code 43 or Code 10)

We'll post more details soon.

Also just in case there's any confusion. We are trying to get the native USB port to function (we haven't got any headers connected to the serial pins on our board).

Also i'm wondering if there's something electrical we might have missed (e.g. you have to pull down some pin or other to ground if you want to use the USB pins as a USB device)

for reference. we're trying to make a motor driver board. it is for an art installation and the designs will be released online for free.

Once the Arduino Zero bootloader has been uploaded, you should be able to upload sketches over the native USB port.

For the USB to function correctly the SAMD21 should be driven by an external 32.768kHz crystal on port pins PA0 and PA1. (The microcontroller's internal oscillator isn't accurate enough).

Other than that there aren't any special requirements in terms of pins being pulled high or low, except for the RESET pin (pulled high). The USB only requires that the D+ and D- lines are connected to the corresponding microcontroller pins.

On connecting the USB the SAMD21 should normally enumerate as: "Arduino Zero (COMx)", or "Arduino Zero bootloader (COMx)" in bootloader mode, (after double tap on reset).

Thanks for the replies!

As MartinL mensioned,
1.We have the external 32.768kHz crystal on PA0 and PA1.
2.Reset button has pulled high resistor (the resistor seems a bit high, 10k+330 ohm. I refered arduino zero's schematic)
3.We originally planed to use USB hub chip (USB2514), but at the end, we connected D+,D- cables to SAMD21 chip directly for testing. (we also cut the lines from USB2514 and ESD chip)

But still exactly same situation.
I can see 'Arduino Zero bootloader(COM3)' in bootloader mode, but It doesn't work with 'code 10' error msg in windows 10.

In schematic, I couldn't find any significant difference with arduino zero or other SAMD21 references.
I'm wondering that if I placed the components too close, it cause the unstable voltage that can be problem of this.

here is my PCB's schematic and layout.
schematic(PCB Schematic hosted at ImgBB — ImgBB)
layout(PCB layout hosted at ImgBB — ImgBB)
assembled PCB(photo hosted at ImgBB — ImgBB)

I would be very grateful if you could look at this and find something.

Many Thanks!

Ban

Hi, I have the same results as the OP, but I am using a cheap SAMD21 Arduino M0 (not Pro) clone.
I think one key is that according to the log, the programming succeeded, but the readback verification reads all 0xFF instead of the real data (this is from my verbose log):

18552 bytes written at address 0x00000000
downloaded 18552 bytes in 0.438170s (41.347 KiB/s)
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0xfffffffc
Error: checksum mismatch - attempting binary compare
diff 0 address 0x00000000. Was 0xff instead of 0xfc
diff 1 address 0x00000001. Was 0xff instead of 0x7f
diff 2 address 0x00000002. Was 0xff instead of 0x00
diff 3 address 0x00000003. Was 0xff instead of 0x20
diff 4 address 0x00000004. Was 0xff instead of 0x15

I would be interested if anyone has successfully programmed the SAMD21 with the ST-Link V2 adapter.

@chrissv
If you check this video : How to burn Arduino Zero bootloader to an Atmel ATSAMD21G18-based custom dev board - YouTube
It seems to show a SAMD21 chip on a custom PCB being flashed with the Arduino Zero bootloader successfully

If you check this video : https://www.youtube.com/watch?v=VQWhjzLoHB8
It seems to show a SAMD21 chip on a custom PCB being flashed with the Arduino Zero bootloader successfully

It needn't be that complicated.

I just used Atmel-ICE Basic programmer connected to a 2x5 way, 1.27mm pitch, SWD connector on my custom board. The board was powered via its native USB port.

On the Arduino IDE: Tools->Programmer->Atmel SAM ICE, followed by Tools->Burn Bootloader.

Thereafter, it's possible to remove the Atmel ICE programmer from the SWD port and upload sketches via your custom board's native USB with the Arduino Zero bootloader.

Unfortunately, since Microchip's acquistion of Atmel, the cost of the Atmel-ICE has more than doubled.

Right! it's suuuuper expensive!
I know there is the bare pcb version of Atmel ICE:

(also delivery takes ages for Korea :frowning:

Has anybody successfully tried SEGGER J-Link EDU Mini?

J-Link is supported by Atmel Studio.

Here's a quick update. I borrowed an Atmel-ICE and used Atmel Studio to try to program the board. I learned that the BOOTPROT bits were set to protect the bootloader region (the value was 0x01). I set the value to 0x07 (disabled) and afterward I was able to use ST-Link to program the bootloader.

Unfortunately I am not aware of any way to change the BOOTPROT register with Adalink. Adalink is just a set of Python scripts, so maybe I'll do some investigating.

-- Steven

That is good to know thanks for sharing. Also, I like the look of that J-Link Mini, think that is what I will start with.

So it seems like there's some consideration to be made regarding Option Bytes.
There are some notes about this at

I'm not clear on how you can read/write these in OpenOCD, or if there is any reference over what these values should be.

Update!!
Just got a JLink Mini Edu in the post
And SUCCESS!!

Tried:

  1. Checking Target Voltage in AtmelStudio/Device Programming - got 0.0V
  2. Used J-Link Configurator to upgrade firmware of the J-Link (ignore the firmware update that happened in Atmel studio - that didn't fix the issue)
  3. Checking Target Voltage in AtmelStudio/Device Programming - got 3.3V and can get Device signature
  4. Uploaded an Arduino sketch via Atmel Studio - SUCCESS
  5. Uploaded Arduino Zero firmware via Atmel Studio - SUCCESS and VERIFY SUCCESS
  6. Upload a program from Arduino IDE using Native Port - SUCCESS
  7. Write to SerialUSB and read in Serial Monitor - SUCCESS

Basically everything works! :slight_smile:
No funny business with option bytes

Thanks for the update. Glad to hear you got it going.

The Segger JLink Mini Edu looks like a neat little programmer. (Not for profit use only though).

Can you also use that JLink Mini Edu within the Arduino IDO to flash a bootloader? Will it show up in the Arduino Software or is it only with AtmelStudio compatible?

@seonghoon

Figure Figure 39-10 on page 862 of the datasheetdatasheet for samd21

indicates that SWCLK needs a 1K pullup resistor, I couldn't see it in your schematic.

Note that a pull-up resistor on the SWCLK pin is critical for reliable operations.

back to the topic, anyone succeed using STLink to burn the bootloader ??

anyone succeed using STLink to burn the bootloader ??

I did a bit of web searching, and found mostly complaints that it doesn't work.
Apparently the STLink firmware doesn't support 16-bit writes over SWD, and a SAMD chip doesn't work when certain 16bit quantities are written 8 bits at a time. Or something like that.