I am working on a project with ATSAMD21J18A which is in a beta testing state.
Everything worked fine for about four weeks but then there was a very strange failure resulting in a “broken” chip. Since more units have to be build and shipped soon, I’m getting a bit nervous and I’m hoping that someone can help me on this.
I figured that DFLL fails to init properly on the “broken” MCU in SYSTEM_CLOCK_DFLL_LOOP_MODE_CLOSED.
In production code, DFLL is configured to 48MHz with an external XOSC32K crystal. For fault finding I also configured it with the internal OSC32K and OSC8M without any improvement.
I have found two errata that might be related to my issue:
For errata 10669 I have found two different workarounds. For the last one from 2019 I do not know how to manage the workaround.
Data sheet from 2016:
1 – The DFLL clock must be requested before being configured
otherwise a write access to a DFLL register can freeze the device.
Errata reference: 9905
Write a zero to the DFLL ONDEMAND bit in the DFLLCTRL register before
configuring the DFLL module.
2 – If the DFLL48M reaches the maximum or minimum COARSE or FINE
calibration values during the locking sequence, an out of bounds
interrupt will be generated. These interrupts will be generated even if
the final calibration values at DFLL48M lock are not at maximum or
minimum, and might therefore be false out of bounds interrupts.
Errata reference: 10669
Check that the lockbits: DFLLLCKC and DFLLLCKF in the SYSCTRL
Interrupt Flag Status and Clear register (INTFLAG) are both set before
enabling the DFLLOOB interrupt
Microchip errata document from 2019:
1.2.2 False Out of Bound Interrupt
If the DFLL48M reaches the maximum or minimum COARSE or FINE calibration values during the locking sequence, an out of bounds interrupt will be generated. These interrupts will be generated even if the final calibration values at DFLL48M lock are not at maximum or minimum, and therefore, may be false out of bounds interrupts.
Enable the DFLL Out Of Bounds (DFLLOOB) interrupt when configuring the DFLL in closed loop mode. In the DFLLOOB ISR verify the COARSE and FINE calibration bits and process as needed.
To understand/find the failure, I’m using the ASF USB bootloader with an character LCD instead of USART. For the LCD delay_XX() is required. On the “broken” MCU delay_XX() is not working properly with the standard clock setup from the ASF project. So the connected character LCD will not be properly initialized on the broken MCU or it will take very long. Toggling a pin with delay_XX() does not work as expected. The USB communication is not working as well.
With a “fresh” MCU everything is working as expected.
When I am using Workaround 1 from 2016 by writing
SYSCTRL->DFLLCTRL.bit.ONDEMAND = false;
in front of system_init() or using DFLL in SYSTEM_CLOCK_DFLL_LOOP_MODE_CLOSED in combination with “systick” delay instead of “cycle”, the LCD is initialized properly. The USB communication is still not working. (“systick” delay is initialized with the current clock frequency, while “cycle” does not require initialization)
Does someone understand the behaviour and/or can explain to me how to make the workaround 1.2.2 (2019 "In the DFLLOOB ISR verify the COARSE and FINE calibration bits and process as needed")?
Is there anything else that can cause the described behaviour?
Do you need more information/code?