Where is the documentation for the SAMD architecture environment?

Recently started development on an Uno R3 but rapidly ran out of SRAM. Acquired a MKR1010 board, and am now struggling to locate definitive documentation for this different development environment. Some clarification and assistance would be welcome

https://www.arduinolibraries.info/ appears to have a comprehensive list of libraries supported in the SAMD architecture environment. Is there a more comprehensive list?
• I used avr-libc: Modules to understand the subset of the standard C/C++ library for the AVR environment. I am currently assuming the SAMD environment supports glibc arm-none-eabi\7.2.1? Is this correct? It is not yet clear where I find equivalent documentation
• From forum entries I think I understand the memory model and EEPROM implementation for the MKR series, but any definitive references would be welcome
• avr-libc implemented various AVR-specific hardware-related functions; including watchdog timer, power/sleep functions, and restart reason. My current assumption is that between the CMSIS library and the SAMD-specific Arduino libraries I will find equivalent SAMD-specific functions. Is this correct?
• Does the SAMD architecture support exception handling?

I think that is the best one. That website uses the official Arduino Library Manager index as its source. There are over 4000 libraries in Library Manager, which is a significant percentage of the Arduino libraries in existence. And they also tend to be the most well maintained of the Arduino libraries since someone had to care enough to submit each library.

I don't have an answer for that. I'm sure one of the other forum members will be able to direct you to more information about the low level specifics. I've been satisfied with the standard Arduino API and libraries in my own explorations of the SAMD boards (my lower level explorations have all been when using AVR chips).

There is no internal EEPROM memory on the MKR boards. You could connect an external EEPROM chip if you wanted though. You'll find some libraries for that listed on arduinolibraries.info.

You can also use the flash memory of the ATSAMD21G18 for non-volatile storage, though perhaps not so convenient to work with as the AVR's internal EEPROM. There is a library for that here:

(use Library Manager to install it)

Thanks. That addresses a number of issues

there are no libraries like for example the avr/wdt. there are only Arduino libraries and the registers level. for registers see the datasheet. for examples on usage of registers just google. I found many when I need it.
many of the Arduino libraries for SAMD have "Zero" in their name (originating in the 0 in the Cortex-M0 CPU architecture of the SAMD21 used first on Arduino M0 and Arduino Zero)

Thanks for your response. Having now read multiple articles (including some of yours) I am still trying to get my head around the high blocking delays in calls to WDT and sleep in the SAMD environment. Will need to rethink my application and my expectations of that application

In a multi-tasking/processing environment delay() only blocks the current task while leaving that time to other tasks. It's essential that also the Idle task is allowed to run and reset the watchdog.

Hi @grumpy_za

The SAMD21 microcontroller allows peripherals such as the TCC/TC timers, RTC, WDT, etc... to be driven by various clock sources asynchronously with respect the the main CPU clock. While this adds flexibility, it also means that certain peripheral registers need to be synchronised to the CPU clock. From a programming perspective, this often this requires polling a SYNCBUSY bit either to indicate that a register is ready to be read, or has successfully been written.

Furthermore, there's an issue reading and writing from/to peripherals clocked from a slow 32kHz source, such as the RTC or WDT, since this generates synchronisation delays in the order of 5 to 6ms to complete, (...yes, milliseconds):

WDT->CLEAR.reg = WDT_CLEAR_CLEAR_KEY;       // Clear the watchdog timer
while (WDT->STATUS.bit.SYNCBUSY);           // Wait for synchronization

However, rather than have the CPU wait for an eternity for the SYNCBUSY bit to be set, it's possible test for the opposite condition and instead simply only write to the WDT register whenever the SYNCBUSY bit has been cleared. This allows the microcontroller whizz around the loop() function without having to wait for synchronisation delay:

if (!WDT->STATUS.bit.SYNCBUSY)              // Check if the WDT registers are synchronized
{
  WDT->CLEAR.reg = WDT_CLEAR_CLEAR_KEY;     // Clear the watchdog timer
}

Note that the register still takes 5 to 6ms to synchronise, there's no way around that, but it does mean that the code doesn't block waiting for synchronisation to complete.

I first saw this workaround in an article on Hackaday:

Thanks for your response

My understanding of the FeatherFault library code is that it implements a not dissimilar approach (one of the solved issues describes the approach). Testing of FeatherFault WDT for a 8 second timeout appears to show no unexpectedly long synchronisation delays. I am currently working on how I integrate their approach with my task scheduler of choice. Will probably take me a while