adafruit/uf2-samdx1

MSC bootloader (based on UF2) for SAMD21

UF2 Bootloader

This repository contains a bootloader, derived from Atmel's SAM-BA, which in addition to the USB CDC (serial) protocol, also supports the USB MSC (mass storage).

UF2

UF2 (USB Flashing Format) is a name of a file format, developed by Microsoft, that is particularly suitable for flashing devices over MSC devices. The file consists of 512 byte blocks, each of which is self-contained and independent of others.

Each 512 byte block consist of (see uf2format.h for details):

• magic numbers at the beginning and at the end
• address where the data should be flashed
• size of data
• data (up to 476 bytes; for SAMD it's 256 bytes so it's easy to flash in one go)

Thus, it's really easy for the microcontroller to recognize a block of a UF2 file is written and immediately write it to flash.

• UF2 specification repo: https://github.com/Microsoft/uf2
• #DeskOfLadyada UF24U ! LIVE @adafruit #adafruit #programming

Features

• USB CDC (Serial emulation) monitor mode compatible with Arduino (including XYZ commands) and BOSSA flashing tool
• USB MSC interface for writing UF2 files
• reading of the content of the flash as an UF2 file via USB MSC
• UART Serial (real serial wire) monitor mode (typically disabled due to space constraints)
• In-memory logging for debugging - use the logs target to extract the logs using openocd
• double-tap reset to stay in the bootloader mode
• automatic reset after UF2 file is written

Board identification

Configuration files for board foo are in boards/foo/board_config.h and board.mk. You can build it with make BOARD=foo. You can also create Makefile.user file with BOARD=foo to change the default.

The board configuration specifies the USB vendor/product name and ID, as well as the volume label (main thing that the operating systems show).

There is also BOARD_ID, which is meant to be machine-readable and specific to a given version of board hardware. The programming environment might use this to suggest packages to be imported (i.e., a package for a particular external flash chip, SD card etc.).

These configuration values can be read from INFO_UF2.TXT file. Presence of this file can be tested to see if the board supports UF2 flashing, while the contents, particularly Board-ID field, can be used for feature detection.

The current flash contents of the board is exposed as CURRENT.UF2 file. This file includes the bootloader address space. The last word of bootloader space points to the string holding the INFO_UF2.TXT file, so it can be parsed by a programming environment to determine which board does the .UF2 file comes from.

Handover

When the user space application implements the USB MSC protocol, it's possible to handover execution to the bootloader in the middle of MSC file transfer, when the application detects that a UF2 block is written.

Details are being finalized.

Bootloader update

The bootloader will never write to its own flash area directly. However, the user code can write there. Thus, to update the bootloader, one can ship a user-space program, that contains the new version of the bootloader and copies it to the appropriate place in flash.

Such a program is generated during build in files update-bootloader*.uf2. If you're already running UF2 bootloader, the easiest way to update it, is to just copy this file to the exposed MSD drive.

The build also generates update-bootloader*.ino with an equivalent Arduino sketch. You can copy&paste it into Arduino IDE and upload it to the device.

Fuses

SAMD21

The SAMD21 supports a BOOTPROT fuse, which write-protects the flash area of the bootloader. Changes to this fuse only take effect after device reset.

OpenOCD exposes at91samd bootloader command to set this fuse. This command is buggy. It seems to reset both fuse words to 0xffffffff, which prevents the device from operating correctly (it seems to reboot very frequently). In scripts/fuses.tcl there is an OpenOCD script which correctly sets the fuse. It's invoked by dbgtool.js fuses. It can be also used to reset the fuses to sane values - just look at the comment at the top.

The bootloader update programs (both the .uf2 file and the Arduino sketch) clear the BOOTPROT (i.e., set it to 0x7) before trying to flash anything. After flashing is done, they set BOOTPROT to 8 kilobyte bootloader size (i.e, 0x2).

SAMD51

The SAMD51s bootloader protection can be temporarily disabled through an NVM command rather than a full erase and write of the AUX page. The boot protection will be checked and set by the self updaters.

So, if you've used self-updaters but want to load it directly, then you'll need to temporarily turn off the protection. In gdb the command is:

set ((Nvmctrl *)0x41004000UL)->CTRLB.reg = (0xA5 << 8) | 0x1a

Build

Requirements

• make and an Unix environment
• node.js in path (optional)
• arm-none-eabi-gcc in the path (the one coming with Yotta will do just fine). You can get the latest version from ARM: https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads
• openocd - you can use the one coming with Arduino (after your install the M0 board support)

Atmel Studio is not supported.

You will need a board with openocd support.

Arduino Zero (or M0 Pro) will work just fine as it has an integrated USB EDBG port. You need to connect both USB ports to your machine to debug - one is for flashing and getting logs, the other is for the exposed MSC interface.

Otherwise, you can use other SAMD21 board and an external openocd compatible debugger. IBDAP is cheap and seems to work just fine. Another option is to use Raspberry Pi and native bit-banging.

openocd will flash 16k, meaning that on SAMD21 the beginning of user program (if any) will be overwritten with 0xff. This also means that after fresh flashing of bootloader no double-tap reset is necessary, as the bootloader will not try to start application at 0xffffffff.

Build commands

The default board is zero. You can build a different one using:

make BOARD=metro_m0

If you're working on different board, it's best to create Makefile.user with say BOARD=metro to change the default. The names zero and metro refer to subdirectories of boards/.

There are various targets:

• all - just compile the board
• burn or b - compile and deploy to the board using openocd
• logs or l - shows logs
• run or r - burn, wait, and show logs

Typically, you will do:

make r

Configuration

There is a number of configuration parameters at the top of uf2.h file. Adjust them to your liking.

By default, you cannot enable all the features, as the bootloader would exceed the 8k(SAMD21)/16k(SAMD51) allocated to it by Arduino etc. It will assert on startup that it's not bigger than 8k(SAMD21)/16k(SAMD51). Also, the linker script will not allow it.

Three typical configurations are:

• HID, WebUSB, MSC, plus flash reading via FAT; UART and CDC disabled; logging optional; recommended
• USB CDC and MSC, plus flash reading via FAT; UART disabled; logging optional; this may have Windows driver problems
• USB CDC and MSC, no flash reading via FAT (or at least index.htm disabled); UART enabled; logging disabled; no handover; no HID; only this one if you need the UART support in bootloader for whatever reason

CDC and MSC together will work on Linux and Mac with no drivers. On Windows, if you have drivers installed for the USB ID chosen, then CDC might work and MSC will not work; otherwise, if you have no drivers, MSC will work, and CDC will work on Windows 10 only. Thus, it's best to set the USB ID to one for which there are no drivers.

The bootloader sits at 0x00000000, and the application starts at 0x00002000 (SAMD21) or 0x00004000 (SAMD51).

Code of Conduct

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

License

See THIRD-PARTY-NOTICES.txt for the original SAM-BA bootloader license from Atmel.

The new code is licensed under MIT.

uf2-samdx1's Issues

SERCOM clocks (20 and 19?) are wrong if 32kHz crystal is used

Chip: SAMD21E18. Board: custom, looks like a Metro M0 or so, with crystal.
I've enabled hardware UART, but I'm having stability problems I think related to baud mismatch with a sensitive host. Might not actually be the cause, but let's pretend it is. If I try to force crystal mode (ext. 32.768kHz) to make the SAMD clock a little more accurate/stable, UART breaks entirely. If I add a little message to the bootloader

#if USE_UART
    /* UART is enabled in all cases */
    usart_open();
    usart_putdata("ready", 5); // My little tester
#endif

I can see that the SAMD sends "ready" at 78 baud, when it should be 115200. Note that it's close enough to 115200 when "crystalless". (78/115200)*48e6 is 32500, so my sneaking suspicion is that the clock configuration for crystalless vs crystal accidentally routes the low frequency input clock to general clock ID 20, which is what the SERCOM is clocked with, instead of the 48MHz system clock. I haven't yet confirmed or tracked down the code I suspect.

This is mostly a placeholder for me to fix myself later if I decide I need to, since I appear to be one of the 1% who want to use a crystal in bootloader, of the 2% who want to use hardware UART.

SMART responses hanging *BOOT drives?

Not sure if this is the right place to put this, but:

There seems to be some evidence that querying the *BOOT drives (and however that's exposed by firmware) for SMART responses hangs them up?

• Multiple devices: https://forums.adafruit.com/viewtopic.php?f=58&t=150232#p741767
• PyPortal: https://forums.adafruit.com/viewtopic.php?f=60&t=149791&p=742995#p742995

I dunno if that's something that gets fixed by Adafruit or upstream, but there's two data points for it.

Thanks!

A+B buttons swapped in MakeCode Arcade on Pybadge

A is B and B is A! I believe this is a pin definition thing.

Lessons learned after Fuses have gone bad(=0xffffffff)

A few comments after my expedition into feather bootloader debugging:

One of the observations that I have had after erasing and flashing the bootloader Of a feather-m0 with the jlink-flash Makefile target was that I somehow managed to set both user fuses to 0xffffffff.

The effect was that the feather in boot loader mode was resetting every second or so because of the hard enabled watchdog fuse.
This was observable on Linux as disconnects on the usb bus and then a reconnect message in domestic.
Just looking at the led showed a bit of dimming which was aborted and turned of and then the thing repeated.

It took me quite some time to figure this out and then a windows machine with Atmel studio to configure the fuses correctly (not to mention: research into what are the right fuse values).

So here maybe a few things for improvement:

• add a watchdog timer reset in a few essential places of the boot loader so that this WD-reset does not happen and you do not brick the board when you have no jtag at hand...
• document the typical fuses to use for each platform (probably boards//board.mk as well as a readme, wiki page or similar)
• document in https://learn.adafruit.com/how-to-program-samd-bootloaders/programming-the-bootloader-with-atmel-studio what may be the reason for the observed flashing and that fuses need to get corrected
• the above link is a bit dated and the studio does not show the hex numbers for the bootloader protection any longer - document the correct “textual version” as well as a link to the recommended fuses.
• provide a way to update the fuses with/or similar to the jlink-flash target (and possibly others as well)
• maybe set the fuses to defaults in the bootloader if they are set badly...

All of this would have helped me resolve the issue quicker...

add board.mk files for all boards

Right now only metro_m0 and metro_m4 have board.mk. The other builds are broken.

Flash again

Drag any UF2 onto the drive. After the file is finished copying, the bootloader will automatically restart. When i want to dray new UF2 onto the drive，must pull out the drive and plug.

make GCM4 drive (at least) larger so we can drag a full 2MB file on

you can make backups but can't re-install

Triggering Bootloader from User Code

I'm looking for a way to boot the Feather M0 into the UF2 bootloader without pressing the reset button twice.
I know how to reset the device through the watchdog but that just creates a reboot loop without entering the bootloader.

How can I trigger a reboot into bootloader either from
a) setting a fuse and rebooting?
b) customize the bootloader to detect a button/pin being held on boot
c) different way other than using the reset button

SAME51J20A vs SAMD51J20A, any changed needed?

I'm bringing up a board I made that has a SAME51J20A. When I picked the SKU, I just assumed that the SAME51 components were implicitly in the "SAMD51" family. Based on the datasheet, the only difference between the SKUs is the CAN peripheral. With that in mind I compiled a .bin for the SAMD51J20A and flashed it to my SAME. It seems to work fine. Is there anything I'm missing, or is this just a naming issue?

Thanks
Tim

Feather M0 gets bricked

Hello, I followed this tutorial (https://learn.adafruit.com/installing-circuitpython-on-samd21-boards/installing-the-uf2-bootloader) on 3 M0 Feather boards and it bricked them all. I followed the directions perfectly every time and I used the Arduino INO file that is posed in this repository. I think there is an issue with the INO file. Also, in case it helps, the boards I used most recently were the Adalogger M0. Thanks for looking into this.

SAMD51 - OTA update using QSPI Flash

Hi,
we use an Adafruit Metro M4 board, which has a 2 MB QSPI Flash storage chip on board.

Is it possible, to use this flash storage chip with the u2f bootloader.

We intended to copy the .uf2-sketch-file over the air (WIFI) to the storage chip and the make programmatically a reset!?

Would this work? Is there anything to configure in the bootloader?

Document how to export uf2 from Arduino

Using Arduino to compile your sketch, it's not very clear how to obtain a uf2 to copy to the MSC. What I figured out and what seems to work is:

• Sketch -> Verify/Compile sketch
• Sketch -> Export compiled Binary
• Sketch -> Show Sketch Folder
• Download https://github.com/Microsoft/uf2/blob/master/utils/uf2conv.py into the sketch directory and make it executable
• Open a terminal and run ./uf2conv.py -c SketchName.ino.board_name.bin
• You should now have a flash.uf2 file in the sketch folder which you cna copy-paste to the mass storage drive.

update-bootloader*.ino Arduino sketch make a brick

Hello everyone, I have been playing with Microsoft's UF2 file system for microcontrollers, I have followed the examples and the Board version MKR1010 has been successfully compiled, in addition to the firmware file * .bin a sketch is generated for the Arduino IDE , but when you upload it to the Board, something breaks and turns it into a brick, so to recover it, I must use OpenOCD in conjunction with a Raspberry, my question is if any of you have tried and solved this problem, I have also made for the SparkFun SAMD21 Dev Breakout Board

linker error

I'm getting a linker error when trying to compile these bootloaders with arm-none-eabi-gcc 6.3.1:

arm-none-eabi-gcc -mthumb -mcpu=cortex-m0plus -Os -g -DSAMD21 -x c -c -pipe -nostdlib --param max-inline-insns-single=500 -fno-strict-aliasing -fdata-sections -ffunction-sections -D__SAMD21G18A__ -Werror -Wall -Wstrict-prototypes -Werror-implicit-function-declaration -Wpointer-arith -std=gnu99 -ffunction-sections -fdata-sections -Wchar-subscripts -Wcomment -Wformat=2 -Wimplicit-int -Wmain -Wparentheses -Wsequence-point -Wreturn-type -Wswitch -Wtrigraphs -Wunused -Wuninitialized -Wunknown-pragmas -Wfloat-equal -Wno-undef -Wbad-function-cast -Wwrite-strings -Waggregate-return -Wformat -Wmissing-format-attribute -Wno-deprecated-declarations -Wpacked -Wredundant-decls -Wnested-externs -Wlong-long -Wunreachable-code -Wcast-align -Wno-missing-braces -Wno-overflow -Wno-shadow -Wno-attributes -Wno-packed -Wno-pointer-sign -I. -I./inc -I./inc/preprocessor -I./boards/itsybitsy_m0 -Ilib/cmsis/CMSIS/Include -Ilib/usb_msc -Ibuild/itsybitsy_m0 -Ilib/samd21/samd21a/include/ src/hid.c -o build/itsybitsy_m0/hid.o
arm-none-eabi-gcc -Lbuild/itsybitsy_m0 -mthumb -mcpu=cortex-m0plus -Os -g -DSAMD21 -Wall -Wl,--cref -Wl,--check-sections -Wl,--gc-sections -Wl,--unresolved-symbols=report-all -Wl,--warn-common -Wl,--warn-section-align -Wl,--warn-unresolved-symbols -save-temps -nostartfiles --specs=nano.specs --specs=nosys.specs
-Tscripts/samd21j18a.ld
-Wl,-Map,build/itsybitsy_m0/bootloader-itsybitsy_m0-v2.0.0-adafruit.5.map -o build/itsybitsy_m0/bootloader-itsybitsy_m0-v2.0.0-adafruit.5.elf build/itsybitsy_m0/flash_samd21.o build/itsybitsy_m0/init_samd21.o build/itsybitsy_m0/startup_samd21.o build/itsybitsy_m0/usart_sam_ba.o build/itsybitsy_m0/utils.o build/itsybitsy_m0/cdc_enumerate.o build/itsybitsy_m0/fat.o build/itsybitsy_m0/main.o build/itsybitsy_m0/msc.o build/itsybitsy_m0/sam_ba_monitor.o build/itsybitsy_m0/uart_driver.o build/itsybitsy_m0/hid.o
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: section .binfo LMA [0000000000001ff0,0000000000001fff] overlaps section .relocate LMA [0000000000001e50,000000000000201b]
collect2: error: ld returned 1 exit status
Makefile:117: recipe for target 'build/itsybitsy_m0/bootloader-itsybitsy_m0-v2.0.0-adafruit.5.bin' failed
make: *** [build/itsybitsy_m0/bootloader-itsybitsy_m0-v2.0.0-adafruit.5.bin] Error 1

GrandCentral MacOS 10.14.4 upload problem

Hi everyone,
i have a problem with the GrandCentral and my MacOS 10.14.4.
I seen this problem in the git https://tinyurl.com/y43gsxwu , but when i update the uf2 to 3.3.0 , the board resent itself during the download of the code in the Arduino IDE.
https://ibb.co/GcsmxK7

Compilation fails if FAT is turned off

A bug introduced in 17cf576#diff-3fe0a6c01ab9fbe7bdf42e7ee8a23c07 breaks compilation if FAT support is optioned off in uf2.h

The fix is trivial, this is mostly a placeholder on which for me to base a pull request momentarily

Match board names more closely to CircuitPython

Some of the board names don't match the board names for CircuitPython, which has caused minor support issues. It would be nice to match them up as much as possible. In some cases, though, (like non-Express Feather M0 boards), there is a single bootloader but multiple CPy builds.

Also the arcade_* boards could be renamed to *_arcade to make them easier to find alphabetically.

LED remains on after reset

It seems like the bootloader will switch on the LED on configured pin LED_PIN. After a reset this LED remains on. This is unexpected behaviour.

Crystal not used?

Hi!

Apologies if this is not the correct place to raise this.

I have a Feather M0 Basic Proto and noticed that all of the bootloaders / uf2 appear to not use the crystal on the board attached to PA00 and PA01 - regardless of which board.

Is there any reason why the X2 crystal is on the board and not used in the default bootloaders? Why have the X2 crystal at all?

I am just curious and interested.

Thank you.

Metro M0 double-click difficult with v1.26.0-adafruit.0 and later

Doing a double-click reset to get to UF2 (pulsing LED) on a Metro M0 with v1.23.1 is easy. But with 1.26.0-adafruit.0 and 2.0.0-adafruit.0, it has become much more difficult for me. I have to try multiple times. I verified by loading the older bootloader and it became easier again. I tried with various different user programs, including just a blinky.

I tried 2.0.0-adafruit.0 on Gemma M0, CPX, and Feather M0 Express, and did not have difficulty doing double-click. I thought it might be CRYSTALLESS vs crystal-controlled clock, but the Feather M0 has a crystal and it's fine.

Speculation: Doing a double-click reset on the Metro M0 with the reset jumper still seems easy. So maybe it's some bounce characteristic of the larger switch vs a timing change since 1.23.1.

SAMD51: UART support timing issues

microsoft#42 from @MartinL1:

Thank you to everyone for the work on the UF2 bootloader.

I'm using a SAMD51 (SAMD51J20A) custom board. The USB CDC works perfectly with the Arduino IDE, however I've been having some trouble getting the UART support to work.

I powered the board without the native USB connection to prevent enumeration, put my custom board into bootloader mode with a double tap of the reset button, then attempted to upload a Blink sketch with the Arduino IDE, using an FTDI USB to serial board on a spare UART port, (in my case SERCOM5).

After looking at the code, I believe that line 128 of the "usart_sam_ba.c" file needs to be changed from:

// Baud rate 115200 - clock 8MHz -> BAUD value-50436
uart_basic_init(BOOT_USART_MODULE, 50436, BOOT_USART_PAD_SETTINGS);

to:

// Baud rate 115200 - clock 48MHz -> BAUD value-63018
uart_basic_init(BOOT_USART_MODULE, 63018, BOOT_USART_PAD_SETTINGS);

This is to account for GCLK0 now being set to 48MHz. The replacement line is taken from the Arduino Zero bootloader.

After this modification I'm now able to upload the sketch using the FTDI board, unfortunately though some timing issues still persist, as this only works on every second attempt.

build failures

I cloned the repo and get the following error whenever try a build. Am I missing something?
I am using "gcc version 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599] (GNU Tools for Arm Embedded Processors 9-2019-q4-major)"

arm-none-eabi-gcc -mthumb -mcpu=cortex-m4 -O2 -g -DSAMD51 -x c -c -pipe -nostdlib --param max-inline-insns-single=500 -fno-strict-aliasing -fdata-sections -ffunction-sections -D__SAMD51J19A__ -Werror -Wall -Wstrict-prototypes -Werror-implicit-function-declaration -Wpointer-arith -std=gnu99 -ffunction-sections -fdata-sections -Wchar-subscripts -Wcomment -Wformat=2 -Wimplicit-int -Wmain -Wparentheses -Wsequence-point -Wreturn-type -Wswitch -Wtrigraphs -Wunused -Wuninitialized -Wunknown-pragmas -Wfloat-equal -Wno-undef -Wbad-function-cast -Wwrite-strings -Waggregate-return -Wformat -Wmissing-format-attribute -Wno-deprecated-declarations -Wpacked -Wredundant-decls -Wnested-externs -Wlong-long -Wunreachable-code -Wcast-align -Wno-missing-braces -Wno-overflow -Wno-shadow -Wno-attributes -Wno-packed -Wno-pointer-sign  -I. -I./inc -I./inc/preprocessor -I./boards/feather_m4 -Ilib/cmsis/CMSIS/Include -Ilib/usb_msc -Ibuild/feather_m4 -Ilib/samd51/include/ src/main.c -o build/feather_m4/main.o
In file included from lib/samd51/include/samd51j19a.h:546,
                 from lib/samd51/include/sam.h:38,
                 from ./inc/uf2.h:7,
                 from src/main.c:76:
lib/cmsis/CMSIS/Include/core_cmFunc.h: In function 'main':
lib/cmsis/CMSIS/Include/core_cm4.h:85:28: error: listing the stack pointer register 'sp' in a clobber list is deprecated [-Werror=deprecated]
   85 |   #define __ASM            __asm                                      /*!< asm keyword for GNU Compiler          */
      |                            ^~~~~
lib/cmsis/CMSIS/Include/core_cmFunc.h:456:3: note: in expansion of macro '__ASM'
  456 |   __ASM volatile ("MSR msp, %0\n" : : "r" (topOfMainStack) : "sp");
      |   ^~~~~
lib/cmsis/CMSIS/Include/core_cm4.h:85:28: note: the value of the stack pointer after an 'asm' statement must be the same as it was before the statement
   85 |   #define __ASM            __asm                                      /*!< asm keyword for GNU Compiler          */
      |                            ^~~~~
lib/cmsis/CMSIS/Include/core_cmFunc.h:456:3: note: in expansion of macro '__ASM'
  456 |   __ASM volatile ("MSR msp, %0\n" : : "r" (topOfMainStack) : "sp");
      |   ^~~~~
cc1: all warnings being treated as errors
Makefile:176: recipe for target 'build/feather_m4/main.o' failed
make: *** [build/feather_m4/main.o] Error 1

10 byte Mode Sense causes a stall

Hello,
I have several different CircuitPython boards which seem to hang when a 10 byte Mode Sense command is issued. I also have two that don't. Those two have bootloader version 1.23.0, the others all have the latest: 3.7.0. From what I can see in the code, that command should work just as well as the 6 byte Mode Sense command. I'm trying to use these boards on FreeBSD, which issues a 10 byte Mode Sense command as part of the device initialization. That causes the device to stall, with the result that it never gets initialized. I tried sending a similar command on a Linux system with the same result: it timed out. Any ideas about why this is happening?

Regards,

Denver

Check chip family before writing

A user used a SAMD21 bootloader on a SAMD51 board: https://forums.adafruit.com/viewtopic.php?f=19&t=159050. It appears to have bricked the bootloader.

We could add a check that the chip family at least matches the expected one, and not do anything if they don't match.

SAMD51 and fuse reprogramming

It seems that fuse reprogramming on samd51 (when all FF are found in user page) doesn't work.

I was in trouble because I was not able to program sketches on my board and using jlink I found bad data on 0x804000. With jlink I forced a flash erase (all 0xFF). Turned off board and turned on again it was always rebooting (because of WDT). boot code had to restore content but I think it didn't

Correct pin assignments in board_config.h

Some of the pin assignments listed in board_config.h for pygamer, pybadge, and pybage_lc are wrong.

• Known wrong: TX and RX are PB16 and PB17, not PA16 and PA17 (reported by @pelikhan).
• The USART boot pins also seem wrong: PA22 and PA23, but those are used for other purposes. They should probably be the same as TX and RX.

All the pins should probably be reviewed against latest schematics.

tagging @ladyada. I can do the pin review.

Error when linking bootloader

I get the following error while building the current master branch. Is there maybe a specific version of arm-none-eabi-gcc required?
I have gcc version 6.3.1 20170620 (15:6.3.1+svn253039-1build1) installed.
This error happens with every board, not just the zero.

$ make all
Building zero
arm-none-eabi-gcc -Lbuild/zero -mthumb -mcpu=cortex-m0plus -Os -g -DSAMD21 -Wall -Wl,--cref -Wl,--check-sections -Wl,--gc-sections -Wl,--unresolved-symbols=report-all -Wl,--warn-common -Wl,--warn-section-align -Wl,--warn-unresolved-symbols -save-temps -nostartfiles --specs=nano.specs --specs=nosys.specs \
	 -Tscripts/samd21j18a.ld \
	 -Wl,-Map,build/zero/bootloader-zero-v2.0.0-adafruit.5.map -o build/zero/bootloader-zero-v2.0.0-adafruit.5.elf build/zero/flash_samd21.o build/zero/init_samd21.o build/zero/startup_samd21.o build/zero/usart_sam_ba.o build/zero/utils.o build/zero/cdc_enumerate.o build/zero/fat.o build/zero/main.o build/zero/msc.o build/zero/sam_ba_monitor.o build/zero/uart_driver.o build/zero/hid.o
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: section .binfo LMA [0000000000001ff0,0000000000001fff] overlaps section .relocate LMA [0000000000001e60,000000000000202b]
collect2: error: ld returned 1 exit status
Makefile:117: recipe for target 'build/zero/bootloader-zero-v2.0.0-adafruit.5.bin' failed
make: *** [build/zero/bootloader-zero-v2.0.0-adafruit.5.bin] Error 1

Creating a custom board

Hi All,

I apologize if this isn't the correct forum, but I'm attempting to use the UF2 bootloader on a custom board.

A little background:
On PC1
I have a SAM D21 Xplained Pro Evaluation Kit that uses a SAMD21J18A. My development environment is Windows 10. I'm able to build one of the examples ($> make BOARD=sparkfun-samd21-dev) and load this onto the Xplained without issue through AtmelStudio. Moreover, I can drag-and-drop a LED toggle example (after modifying the start address to "-Wl,--section-start=.text=0x2000") that's been converted to UF2 and see the LED toggle as expected.

Problem:
On PC2 (custom board running Windows 10 with a SAMD21E17D connected)
Now, I'm trying to use a custom board that uses a SAMD21E17D. I copied the board\sparkfun-samd21-dev, renamed the directory, and modified the board_config.h (mostly to see a different LED blink during boot mode).

I also modified .\uf2-samdx1\scripts\samd21j18a.ld as the Makefile seems hardcoded to this file. The change I made here was to modify the ram LENGTH = 0x00004000 (to match the datasheet) and change the stack size from 0x2000 to 0x1000.

I'm able to build and load the custom board through AtmelStudio onto my custom target (PC2); this time using a Atmel-ICE debugger. I can see the LED fade in/out and the device enumerate as a MSD with the current.uf2, index.htm, and info_uf2.txt files while it's in boot mode. Now, when I try to drag-and-drop my new uf2, nothing happens. After a minute or so, the SAMD MCU appears to reset (no double-reset though, so it doesn't re-enter boot mode)

I'm a bit stuck on how to proceed debugging this issue. Any guidance is much appreciated.

Thanks,
Greg

Grand Central Issue - Klipper 3D Printer Firmware

I'm attempting to use the Grand Central M4 as a replacement for the MEGA 2560/RAMPS combination.

Per instructions on the Klipper FW project, which supports the SAMD51 chipsets, I configured Klipper with the following selactable MCU options:

[*] Enable extra low-level configuration options
Micro-controller Architecture (SAMD21/SAMD51) --->
Processor model (SAMD51P20 (Adafruit Grand Central)) --->
Clock Reference (32.768Khz crystal) --->
Bootloader offset (16KiB bootloader (Arduino M0)) --->
USB ids --->
[ ] Specify a custom step pulse duration
() GPIO pins to set at micro-controller startup 

compiled the base FW and loaded it on the controller using bossa command:
bossac -u -p COM7 --offset=0x4000 -w .\Metro\klipper.bin -v -b -R

making of the klipper.bin file was successful and the flash was also successful.

When getting the Raspberry Pi (main controller of Klipper) to talk to the MCU, I'm receiving the following in Klipper's log:

Starting serial connect
Loaded MCU 'mcu' 75 commands (v0.7.0-445-g2d86448-dirty-20190726_152807-octopiper / gcc: (15:5.4.1+svn241155-1) 5.4.1 20160919 binutils: (2.27-9+9) 2.27)
MCU 'mcu' config: SOFT_PWM_MAX=256 STEP_DELAY=2 ADC_MAX=4095 RESERVE_PINS_crystal=PA0,PA1 CLOCK_FREQ=120000000 RESERVE_PINS_USB=PA24,PA25 MCU=samd51p20a STATS_SUMSQ_BASE=256
Sending MCU 'mcu' printer configuration...
got {'#receive_time': 3521.247487406, u'crc': 2681911713L, u'is_shutdown': 0, '#name': u'config', u'is_config': 1, '#sent_time': 3521.246409177, u'move_count': 1024}
Configured MCU 'STATS_SUMSQ_BASE' (1024 moves)
Starting heater checks for heater_bed
Starting heater checks for extruder
Stats 3521.3: gcodein=5 mcu: mcu_awake=0.000 mcu_task_avg=0.000000 mcu_task_stddev=0.000000 bytes_write=3491 bytes_read=3613 bytes_retransmit=9 bytes_invalid=0 send_seq=167 receive_seq=166 retransmit_seq=2 srtt=0.002 rttvar=0.001 rto=0.025 ready_bytes=20 stalled_bytes=0 freq=119990138 heater_bed: target=0 temp=0.0 pwm=0.000 print_time=2.560 buffer_time=0.212 print_stall=0 extruder: target=0 temp=0.0 pwm=0.000
MCU 'mcu' is_shutdown: ?0
clocksync state: mcu_freq=120000000 last_clock=262206647 clock_est=(3520.790 215118672 119990138.906) min_half_rtt=0.000181 min_rtt_time=3521.128 time_avg=3520.789(0.018) clock_avg=215118672.948(2212577.267) pred_variance=10614411703.692
Dumping serial stats: bytes_write=3431 bytes_read=3566 bytes_retransmit=9 bytes_invalid=0 send_seq=166 receive_seq=166 retransmit_seq=2 srtt=0.002 rttvar=0.001 rto=0.025 ready_bytes=35 stalled_bytes=5
Dumping send queue 100 messages

I have a support ticket also opened with Klipper: Klipper3d/klipper#1841

Currently we do not know what direction to go.

Kevin @ Klipper stated in his ticket:

Unfortunately, you've hit the same issue described in #1673 - the micro-controller is responding with nonsensical messages (MCU 'mcu' is_shutdown: ?0) which indicates some sort of severe corruption of the micro-controller state. We've tested a number of the SAMD51 chips (I have the SAMD51G19 and SAMD51J19 chips and I know of several users using the SAMD51N19) - there must be something wrong with the SAMD51P20 support, but it is unclear what that is.

Can you review an provide some advise?

klippy.log

Feather M4 express: bytes above BOOTPROT being zeroed

Complete details provided in this post:
https://forums.adafruit.com/viewtopic.php?f=57&t=158718

Feather M4 Express does not launch user code because memory locations at the beginning of unprotected FLASH memory are being cleared (set to 0x0) during power-on.

Arduino IDE v1.8.10
Adafruit Feather M4 Express; part #3857
Adafruit FeatherWing OLED 128x32; part #2900
Adafruit bootloader v3.7.0
Adafruit_SSD1306 library v2.0.2

No additional hardware is required. Just stack a Feather and OLED, install 'my version 3' then cycle power on/off. The failure usually occurs within 100 on/off power cycles but it is random and may require thousands of power-on-cycles to observe the failure. I automated cycling power at 500ms ON, 500ms OFF.

'my version 3' application code provided below

[EDIT: turned into an attachment for easier downloading -- @dhalbert]

v3.ino.txt

Metro M0 and CPX show bright NeoPixel when starting user Arduino program

As reported by a user: https://forums.adafruit.com/viewtopic.php?f=60&t=128527, and observed by me and others.

Metro M0 Express shows bright green NeoPixel
CPX shows bright bluish NeoPixel (first one only).

Shouldn't check_start_application clear *DBL_TAP_PTR on BOD reset, also?

I originally filed this against the microsoft repo, but maybe it’ll get more attention here.

I've been experiencing an issue where poor power rails cause the bootloader to be entered spontaneously. You can simulate this by applying power to a Feather M0 by holding the ends of two wires together to complete the path to the positive power supply, and then rub them to make a series of interrupted power spikes.¹

I think this is triggering the brown-out detection circuitry, and setting the RESET_CONTROLLER->RCAUSE.bit.BODxx bit(s), rather than RESET_CONTROLLER->RCAUSE.bit.POR. The code, as written in main.c interprets this as the user pressing the reset button, and it enters the boot loader.

Ignoring SINGLE_RESET, I think more robust code might look like this. I have not tested this as I currently have no way to load the boot loader:

    if (RESET_CONTROLLER->RCAUSE.bit.POR            //  If power-on reset
        || RESET_CONTROLLER->RCAUSE.bit.BOD12       //  or either brown-out
        || RESET_CONTROLLER->RCAUSE.bit.BOD33 ) {   //  reset, clear *DBL_TAP_PTR
        *DBL_TAP_PTR = 0;
    } else if (RESET_CONTROLLER->RCAUSE.bit.EXT     //  If user pressed reset button
                && *DBL_TAP_PTR == DBL_TAP_MAGIC) { //  AND it’s the second time through
        *DBL_TAP_PTR = 0;
        return; // stay in bootloader
    } else {                                        //  This should probably check RESET_CONTROLLER->RCAUSE.bit.EXT, too
        if (*DBL_TAP_PTR != DBL_TAP_MAGIC_QUICK_BOOT) {
            *DBL_TAP_PTR = DBL_TAP_MAGIC;
            delay(500);
        }
        *DBL_TAP_PTR = 0;
    }

This change should do a couple of things: treat power-on and brown-out-detect resets the same, and only count a /RESET assertion as the second press.

I’m not sure if the SAM51 has different BOD bits.

Note: I took a chance and flashed this bootloader onto a chip, and bricked it. I've ordered an ATMEL-ICE, should be here tomorrow. Not sure if I loaded it incorrectly (I used the resulting .ino file), or if this code doesn't work. A different bug suggests maybe it's the .ino file, and not my changes (especially since my changes should only result in either the bootloader always triggering, or never triggering).

---

Footnotes

1. In my case, I have an Adafruit solar lipo charger. When the battery is depleted and the sun is just beginning to shine on the panel, the power provided to the load can be spotty. ↩

GCM4 Boot mode and L led

Grand central M4, when in boot mode, turn on (fading) the L led. This led is connected to D13 that may be an used pin, and none know what is connected to it...is not too dangerous to light it?
Isn't better too use the TX/RX yellow led that is connected only to a led?

Builds for SAMD51G19A broken - unknown cause

Afternoon,

I have been trying to build a bootloader for the SAMD51G19A but hit a small road block.

I forked the repository on Wednesday (last week). My builds from that time have a version code of v3.6.0.0-2-g4fdf0fe. They work perfectly fine on the board.

I then ran git submodule update about 2 hours ago and now all the builds I make do not work on the board. They have version code v3.6.0-4-g09c839b-dirty.

I cannot find what changed after the sub-module update. According to the operating system nothing changed except for the builds. I can clearly see in the console history that this change happened after ran git submodule update.

According to the debugger, the bootloader is crashing on line 480 of src/cdc_enumerate.c.

The only reason I updated was because someone else was getting the dodgy g09 builds but I was not.

There are no obvious changes to any submodules or this repository (except for one on June 14). Is anyone able to explain how the version code gets generated and then I might be able to back trace this issue.

Thank you

VirtualBox Ubuntu 16.04.5
Repository Fork: https://github.com/wallarug/uf2-samdx1
Build Command: make BOARD=robohatmm151

Error using update bootloader sketch for SAMD51

I downloaded the sketch for updating the bootloader of Metro M4 (update-bootloader-metro_m4-v2.0.0-adafruit.5.ino from https://github.com/adafruit/uf2-samdx1/releases/tag/v2.0.0-adafruit.5).

I'm using the Arduino IDE 1.8.5 on Mac OS X.

If I open the sketch an click "Verify/Compile" many error messages occurs:
"update-bootloader-metro_m4-v2.0.0-adafruit.5:1062: error: 'volatile struct NVMCTRL_INTFLAG_Type::' has no member named 'READY'
while (NVMCTRL->INTFLAG.bit.READY == 0) {...."

The sketch seems to be generated for the SAMD21 chip.

On the SAMD21 and SAMD51 the NVMCTRL_INTFLAG Types (and some others) are different.

If I download the uf2-samdx1 bootloader and compile the "update-bootloader-metro_m4-xxx.ino" the same error occurs.

Trouble with a NeoPixel on a Trinket M0 clone

I'm trying to make a direct port of this bootloader to a board is, that for all bootloader intents and purposes, a Trinket M0, with a crystal and a neopixel instead of a dotstar.

board_config.h:

#ifndef BOARD_CONFIG_H
#define BOARD_CONFIG_H

#define CRYSTALLESS    0

#define VENDOR_NAME "Adafruit Industries"
#define PRODUCT_NAME "Trinket M0"
#define VOLUME_LABEL "TRINKETBOOT"
#define INDEX_URL "http://adafru.it/3500"
#define BOARD_ID "SAMD21E18A-Trinket-v0"

#define USB_VID 0x239A
#define USB_PID 0x001E

#define LED_PIN PIN_PA14 //NOTE- LED MOVED.
//#define LED_TX_PIN PIN_PA27
//#define LED_RX_PIN PIN_PB03

#define BOARD_NEOPIXEL_PIN PIN_PA16 // NOTE - SAME SERCOM DIFFERENT PIN
#define BOARD_NEOPIXEL_COUNT 1

#endif

The issue I'm having is that, on main.c line 138:

#if defined(__SAMD21E18A__)
    RGBLED_set_color(COLOR_LEAVE);
#endif

this RGBLED_set_color(COLOR_LEAVE); ALWAYS sets my neopixel full-bright-white. Whether I manually override the value, regardless of what I overwrite it with, etc. The LED writes on the way into other modes, like main.c 199: RGBLED_set_color(COLOR_START); all work fine. In fact, if I add a line on 200 to write whatever color I like, that works too. It's only on 139 that the write seems to fail.

If I comment out the LED write on 139, of course it doesn't happen - the LED goes red to indicate bootloader, then doesn't get cleared when the user code launches.

Also noteworthy, I tried this experiment on main.c 198:

    // not enumerated yet
    RGBLED_set_color(COLOR_START);
    delay(5000);
    RGBLED_set_color(0x0000FF);
    delay(10000);
    RGBLED_set_color(0x090900);
    led_tick_step = 10;

What's odd is that the delay()s don't work right. I had to set them to 5 and 10 seconds just to be perceptible - both of those are still well under a second. Perhaps my clock delcaration up there is off somehow? I also tried simply commenting out #define CRYSTALLESS 1 as is the scheme in the Metro M0 configuration, but that didn't change any behavior. The timing does APPEAR to be different if I have #define CRYSTALLESS 1 enabled vs disabled, but I can't tell how since the timings are so short as-is.

And finally, just for fun, if I change line 138 to:

#if defined(__SAMD21E18A__)
    RGBLED_set_color(COLOR_LEAVE);
    delay(5000);
    RGBLED_set_color(0x0000FF);
    delay(10000);
    RGBLED_set_color(0x090900);
#endif

the LED still goes full bright white. One would logically assume it DOES get written 3 times, white each time, and I just can't tell that.

I DID just figure out a second ago that in that ludicrous last case, it takes the bootloader 27 seconds after a reset button hit to enter user code. So maybe there's something funky going on like the clocking gets reconfigured by the time it gets to 138, and therefore the LED write timing is all messed up?

Changes needed for SAMD21E15

What would need to be done to make a version of this bootloader that works on a SAMD21E15? I have 2 chips on breakouts, both a SAMD21E15 and a ATSAMD21E18 the Trinket M0 bootloader works fine on the *E18 but not on the *E15.

I'm not sure what would have to be done to make this work. The only difference between the two chips is the capacities of the two:

• SAMD21E18A has 256KB of Program memory and 32 KB of Ram
• SAMD21E15B has 32KB of Program memory and 4 KB of Ram

I am not much of a programmer but i can take some guidance and see if i can make it work but i do not know where to start.

How to restore the bootloader on SAMD51?

It seems I accidentally broke the bootloader in Feather M4 while trying to flash an example code downloaded from Atmel Start. At the moment I only get fast blinking yellow led. No USB device. Double tapping reset button does not bring bootloader mode.

$ bossac --info --debug --port /dev/cu.usbmodem1411 --erase --write --verify --reset  AtmelStart.bin
Set binary mode
version()=v1.1 [Arduino:XYZ] Jun 25 2018 17:55:55
Connected at 921600 baud
readWord(addr=0)=0x2000d6a0
readWord(addr=0xe000ed00)=0x410fc241
readWord(addr=0x4)=0x58d
readWord(addr=0x41002018)=0x60060005
write(addr=0x20004000,size=0x34)
writeWord(addr=0x20004030,value=0x80)
writeWord(addr=0x20004020,value=0x20008000)
version()=v1.1 [Arduino:XYZ] Jun 25 2018 17:55:55
readByte(addr=0x804000)=0x39
readByte(addr=0x804001)=0x92
readByte(addr=0x804008)=0xff
readByte(addr=0x804009)=0xff
readByte(addr=0x80400a)=0xff
readByte(addr=0x80400b)=0xff
Device       : ATSAMD51x19
Version      : v1.1 [Arduino:XYZ] Jun 25 2018 17:55:55
Address      : 0x0
Pages        : 1024
Page Size    : 512 bytes
Total Size   : 512KB
Planes       : 1
Lock Regions : 32
Locked       : none
Security     : false
BOD          : false
BOR          : true
Erase flash
chipErase(addr=0)

Done in 5.005 seconds
Write 10656 bytes to flash (21 pages)
[                              ] 0% (0/21 pages)write(addr=0x20004034,size=0x1000)

SAM-BA operation failed

I reckon I could purchase a SWG programmer such as Black Magic Probe to reflash the bootloader. Are there any other options?

metro_m4 can only write 256kB of flash

boards/metro_m4/board.mk sets CHIP_VARIANT = SAMD51J18A. That's the 256kB version of the SAMD51. So UF2 will not write in the second half of flash on Metro M4 boards, which use SADM51J19A (512kB).

RadioFruit M0 points to Feather M0 Express

The board_config.h file points the Feather M0 Express.

uf2-samdx1/boards/radiofruit_m0/board_config.h

Line 7 in c44317f

#define INDEX_URL "http://adafru.it/3403"

What are the boards supported by this release? RFM69? RFM9x? Bluetooth?

Thanks,
Martin

Bug in gendata.py

I may be using a different version of Python than you, but when I run gendata.py I get this error in line 34:

TypeError: 'float' object cannot be interpreted as an integer

I fixed it by changing

for row in range(bootloader_size / 16):

to

for row in range(bootloader_size // 16):

ItsyBitsy M4 Express is not marked CRYSTALLESS

From what I can gather from https://learn.adafruit.com/introducing-adafruit-itsybitsy-m4, including the schematic at https://learn.adafruit.com/assets/55481, like the ItsyBitsy M0 Express board that is marked CRYSTALLESS, the M4 does not have a crystal.

[Question] is 'setBootProt' dangerous?

Hello,

I'm creating code to program SEE size and I'm getting some hints from function above.

When fuses to set boot code protection are to be written, code does:
exec_cmd(NVMCTRL_CTRLB_CMD_EP);
this will format a page so 512 bytes set to 0xFF (but why format? if we only clear bits no format is required)
program then write fuses[0] and fuses[1] (first 64 bits)
and finally:
exec_cmd(NVMCTRL_CTRLB_CMD_WQW);

but SAMD51 datasheets writes:

159:128 Reserved Factory settings - do not change.

so do we destroy something?

IBDAP and Armstart.com seem to be defunct

Your readme still suggests the IBDAP.

SAMD51: 48MHz GCLK0 Output on pin PB14

leftover debugging clock output?

microsoft#43 from @MartinL1:

Shouldn't the lines 8 and 9 in the "init_samd51.c" file be commented out?

// Output GCLK0 to Metro M4 D5. This way we can see if/when we mess it up.
PORT->Group[1].PINCFG[14].bit.PMUXEN = true;
PORT->Group[1].PMUX[7].bit.PMUXE = 12;

It's just that these lines will cause the SAMD51 to output GCLK0 at 48MHz on port pin PB14, whenever the board's in bootloader mode. This is digital pin D5 on the Metro M4.

bin2uf2.js and uf2conv.py script appstart same for samd21 and samd51?

Just searching through the code and noticed that both scripts mentioned assume the appstart at 0x2000. However, (unless I'm confused) when compiling for samd51, the code will end up being 0x4000 (16k) large. Shouldn't appstart be 0x4000 in that case?

edit: Same thing with the sketch.cpp used as a base for update-bootloader...ino

Accessing QSPI Flash of SAMD51 from bootloader

Hi,
is it possible to have access to the QSPI flash in the uf2 bootloader program?

How can I read and write to the QSPI flash?

Bossa upload stopped on M0 feather custom board.

I always have problems uploading with Bossa: once in a while the upload process stops and requires a double click on reset to get going. Sometimes this doesn't even work and it is stuck leaving the Led 13 on
Never had problems using the "normal" bootloader flashed with the Arduino IDE and Atmel-Ice

Changes to make SAMD51G18A work

@dhalbert and anyone else - sorry this isn't an issue with your working code but I was hoping you could help. I have been developing with a Metro M4 express and then moved on to the ItsyBitsy M4 and now I have finally moved to my own custom board, I have realised I have the SAMD51G18A variant, rather than the 19A that only now do I see is in the dev boards that preceded it. Which parts of which files do I need to change to make a bootloader for the 18A variant? Help!

Pin definitions for 'A' + 'B' buttons reversed on PyBadge in MakeCode Arcade

The hardware button on pybadge labeled 'A' is activating the 'B' pin and vice versa when using MakeCode Arcade generated .uf2 files.
To replicate,

• launch arcade.makecode.com editor

• paste this into the javascript editor:
  enum SpriteKind { Player, Projectile, Food, Enemy } controller.A.onEvent(ControllerButtonEvent.Pressed, function () { game.showLongText("You pressed 'A'", DialogLayout.Bottom) }) controller.B.onEvent(ControllerButtonEvent.Pressed, function () { game.showLongText("You pressed 'B'", DialogLayout.Bottom) })

• pick the pybadge board from settings gear menu

• download the .uf2

• press reset on pybadge

• drag on the .uf2

• try out the A and B buttons. The text will indicate the problem.