Whilst I have no experience with this I could work on creating a PR to add it myself, but I could use some help/input on what needs to be done to add support for a new board.

The best place to start would be to take an existing board from ports/samd/boards/ that matches the one you want and adapt it.

Adapting for a new board is pretty easy. The most laborious part is changing pins.csv, but any firmware for a SAM21 board should run a the device. Only the board name and the pin names may be wrong, but you can use the port numbers to designate a pin, like Pin("PA04").

@simonvanderveldt I had an old MKRZERO lying around and I've managed to implement this board.
First you need to flash the UF2 bootloader (follow this Adafruit guide ) and then I used ADAFRUIT_ITSYBITSY_M0_EXPRESS as a template.
I changed the board name and pins.csv to match the pinout and schematics, compiled and uploaded firmware.uf2 to MRZEROBOOT drive and that's it.

MicroPython v1.19.1-831-g4f3780a15-dirty on 2023-01-21; MKRZERO with SAMD21G18A
Type "help()" for more information.

I may make a PR but in the meantime check my branch mkrzero

@Carglglz That's very good. The Arduino MKR Zero looks like a good board, with the SD card, the crypto chip and the available JTAG interface. Please make a PR, when you think you're ready.

Since the board has a 32kHz crystal, you could try to set in mpconfigboard.h

#define MICROPY_HW_XOSC32K (1)
instead of:
#define MICROPY_HW_DFLL_USB_SYNC (1)

That results in:

• availability of machine.RTC()
• better clock precision when the board is not connected to USB
• lower jitter of machine PWM
• a slightly shorter start-up time.

When using MICROPY_HW_DFLL_USB_SYNC, the clock reference is the 1 kHz USB sync pulse, when connected, and the internal 32kHz RC oscillator, when USB is not connected. The latter has a quite high temperature drift. and using a 1 kHz sync signal for the 48MHz and 120Mhz oscillators causes more jitter than using the 32kHz signal.

Just another note: Since the firmware supports touch1200, you may use the little script below to enable the bootloader:

import serial
import time
import sys
com=serial.Serial(sys.argv[1], 1200, dsrdtr=True)
com.dtr=False
com.rts=False
time.sleep(0.2)
com.close()
time.sleep(4)

It requires the pyserial module on the PC. A double push on reset should also enable the bootloader.

@robert-hh thanks, really nice work with the samd port 👏🏼

The Arduino MKR Zero looks like a good board, with the SD card, the crypto chip and the available JTAG interface.

Yes, so far I've only done a quick test with the led and UART and so far so good, SD and crypto chip will go next...

Since the board has a 32kHz crystal, you could try to set in mpconfigboard.h

I wasn't aware of this, I did tried importing RTC which didn't work so thanks for the explanation 👍🏼.

Also any hint on checking what is the maximum firmware size for the SAMD21G18A?, Arduino docs says

256KB Flash

but somehow the uf2 size is

Converted to uf2, output size: 379392, start address: 0x2000
Wrote 379392 bytes to build-ARDUINO_MKRZERO/firmware.uf2

I'm missing something obvious I guess?

Just another note: Since the firmware supports touch1200, you may use the little script below to enable the bootloader:

Thanks for this too, it would be nice to automate the flashing process tbh ⚙️

The flash size id 256k. Of that, 192 k are reserved by the code and almost fully used, 64k for the file The .uf2 files are about twice as large as the binary image itself. That's why you get the confusing number.
You can force the machine.RTC class to be included by setting in mpconfigboard.h:
#define MICROPY_PY_MACHINE_RTC (1)

But without a crystal the RTC clock would be controlled the internal low power 32kHz RC oscillator. And even it if is quite good for an RC oscillator, it is not good enough for a clock. But if you need the RTC class for consistency, you can enable it.

Edit: There is an extended comment in mcu/samd21/clock_config.c, explaining the clock configuration settings.

@Carglglz Nice! I don't use the MKR Zero anymore, but good to see that this might still happen! :)

The flash size id 256k. Of that, 192 k are reserved by the code and almost fully used, 64k for the file The .uf2 files are about twice as large as the binary image itself. That's why you get the confusing number.

It would be interesting to set a maximum in Make/CMake ? So if the build size goes over it automatically fails, isn't this what happens in other device based ports? 🤔

Good news are that I2C and SPI work, the bad news are that there is actually no crypto chip (even it is in the schematics?) and it cannot mount the microSD. It can be detected and initiated but that's it, trying to mount returns OSError 19...

At the end of the build process the linker tells the size of the binary. Like with these lines:

   text	   data	    bss	    dec	    hex	filename
 184596	    148	   1788	 186532	  2d8a4	build-ARDUINO_MKR_ZERO/firmware.elf

The 186532 plus 0x2000 is the total size in flash which is required. So it's 190k at the moment. 0x2000 is the start address of the code in flash.
About SD-Card: The SAMD port does not support FAT at the moment. That's why you get the OSError 19 which tells, that the file system is not known. You could try to enable FAT by:

• adding the lines below to mpconfigboard.mk

MICROPY_VFS_FAT ?= 1
SRC_C += \
	fatfs_port.c

• adding the FAT settings to mpconfigboard.h:

// fatfs configuration used in ffconf.h
#define MICROPY_FATFS_ENABLE_LFN            (1)
#define MICROPY_FATFS_RPATH                 (2)
#define MICROPY_FATFS_MAX_SS                (4096)
#define MICROPY_FATFS_LFN_CODE_PAGE         437 /* 1=SFN/ANSI 437=LFN/U.S.(OEM) */

This will increase however the space for the code to 204k. So you have reduce the size of the on-board file system by changing boards/samd21x18a.ld e.g. to the lines below:

_oflash_fs = ORIGIN(FLASH) + 192K + 16K - 8K;
_sflash_fs = LENGTH(FLASH) - 192K -16K + 8K - 1;

Which decrease the file system to 48k and increase the space for the code by 16k. You can save that to a specific .ld file and reference that in the board's mpconfigboard.mk. At the moment, there is no warning if the code overlaps the file system. The decrease of the file system may be acceptable if you have only a small script there which mounts the SD card. Note that FAT also allocates a 4k buffer from RAM, and the space for the heap is already small, like ~20k.

b.t.w.: Did you try enabling the crystal?

About the crypto chip: On the picture of the board at arduino.cc I see a non-populated chip area between the MCU and the SD card connector. Most likely that the place where the crypto chip ought to be. The connections look right.

@robert-hh

About SD-Card: The SAMD port does not support FAT at the moment. That's why you get the OSError 19 which tells, that the file system is not known

Well that makes sense 😅 , I will try that next...

b.t.w.: Did you try enabling the crystal?

Yes, it did work and RTC too 👍🏼 , I will update whether I manage to mount the SD or not.

bout the crypto chip: On the picture of the board at arduino.cc I see a non-populated chip area between the MCU and the SD card connector. Most likely that the place where the crypto chip ought to be. The connections look right.

Yes I can see the footprint now you've mentioned it. I guess it could be soldered but I have no ATECC508A chip at the moment to try...

@robert-hh FAT enabled and SD mounted successfully 🎉 . I will do the PR soon.