I recently acquired a few Sparkfun SAMD21 Pro RF boards, and found that several known-good USB firmware images (that I had used on other SAMD11 and SAMD21 designs) had major USB connectivity issues. It was hit or miss whether the USB enumeration would even happen, and an external USB sniffer showed major data corruption.
I eventually figured out that the Sparkfun fork of the “Arduino Zero” bootloader seems to use source code where the DFLL48M is placed in a mode where it is disciplined by an external 32k crystal.
https://github.com/sparkfun/Arduino_Boa … aders/zero
In contrast, the known-good firmware used the USB Clock Recovery Mode (USBCRM) where the USB SOF message (1kHz internal) to discipline the DFLL48M.
By substituting the 32k crystal based mode, the (now-modified) known-good firmware projects work again.
I’ve never had an issue with Atmel’s SAMD21 and SAMD11 Xplained Pro boards, or with custom PCBs. The USBCRM mode should be universal, as it doesn’t depend on external components (like the 32k crystal).
There is no verbiage in the SAMD2x datasheet to indicate special requirements for USBCRM. AT07175 (the SAM-BA app note that served as a basis for the “Arduino Zero” bootloader) makes no special requirements. The SAMD21 Pro RF PCB layout makes the USB differential lines go through several layer changes, and they lack a ground plane beneath them, but it isn’t a truly horrible layout. There could also perhaps be some decoupling / noise-filtering issues.
Is there any insight into why:
a) USB Clock Recovery Mode (USBCRM) is seemingly broken with Sparkfun
b) Sparkfun chose to include the seemingly optional 32k crystal
I’m wondering if (b) is a consequence of (a)?
I have a few open-source firmware projects on github that use the SAMD11/SAMD21, so I’m contemplating having to add verbiage that warns about Sparkfun (or “Arduino Zero”) PCBs and suggests a code substitution. However, I’d rather have a one-size-fits-all ‘it just works’ approach; USBCRM should have been this.
Thanks.