I love the WDTZero library as it adds a very high level of reliability to my project. It has been a game changer.
The following from the Arduino forum is an excellent description of the conflict between the WDTZero and RTCZero libraries. Before making this library change, I spent quite some time trying to figure out why the RTC was losing about 3 minutes a day.
To help others using both libraries, it would be great to have this description added to the example program and, if relatively easy to do, have a switch or some other means to set up the WDTZero to configure the GLK2 clock to the external crystal like the RTC Zero code or use another clock without a user having to make changes to the actual WDTZero library code.
"Examining the WDTZero and RTCZero libraries, it appears as though the cause of the conflict is that both attempt to re-configure GLK2 as their clock source. The WDT attempts to set it to the internal OSCULP32K ultra low power oscillator, while the RTC attempts to set it to the external crystal XOSC32K. Both libraries divide the 32k generic clock source by 32, to generate a 1.024kHz signal.
You could try setting up the RTCZero library first and then the WDTZero library with the following lines from 58 to 66 commented out in the “WDTZero.cpp” file:
// Generic clock generator 2, divisor = 32 (2^(DIV+1)) = _x
//GCLK->GENDIV.reg = GCLK_GENDIV_ID(2) | GCLK_GENDIV_DIV(_x);
// Enable clock generator 2 using low-power 32.768kHz oscillator.
// With /32 divisor above, this yields 1024Hz clock.
//GCLK->GENCTRL.reg = GCLK_GENCTRL_ID(2) |
// GCLK_GENCTRL_GENEN |
// GCLK_GENCTRL_SRC_OSCULP32K |
// GCLK_GENCTRL_DIVSEL;
//while(GCLK->STATUS.bit.SYNCBUSY);
This should allow the WDT to simply connect to GCLK2, which has already been configured by the RTCZero library for the external crystal XOSC32K clock source."
I love the WDTZero library as it adds a very high level of reliability to my project. It has been a game changer.
The following from the Arduino forum is an excellent description of the conflict between the WDTZero and RTCZero libraries. Before making this library change, I spent quite some time trying to figure out why the RTC was losing about 3 minutes a day.
To help others using both libraries, it would be great to have this description added to the example program and, if relatively easy to do, have a switch or some other means to set up the WDTZero to configure the GLK2 clock to the external crystal like the RTC Zero code or use another clock without a user having to make changes to the actual WDTZero library code.
"Examining the WDTZero and RTCZero libraries, it appears as though the cause of the conflict is that both attempt to re-configure GLK2 as their clock source. The WDT attempts to set it to the internal OSCULP32K ultra low power oscillator, while the RTC attempts to set it to the external crystal XOSC32K. Both libraries divide the 32k generic clock source by 32, to generate a 1.024kHz signal.
You could try setting up the RTCZero library first and then the WDTZero library with the following lines from 58 to 66 commented out in the “WDTZero.cpp” file:
// Generic clock generator 2, divisor = 32 (2^(DIV+1)) = _x //GCLK->GENDIV.reg = GCLK_GENDIV_ID(2) | GCLK_GENDIV_DIV(_x); // Enable clock generator 2 using low-power 32.768kHz oscillator. // With /32 divisor above, this yields 1024Hz clock. //GCLK->GENCTRL.reg = GCLK_GENCTRL_ID(2) | // GCLK_GENCTRL_GENEN | // GCLK_GENCTRL_SRC_OSCULP32K | // GCLK_GENCTRL_DIVSEL; //while(GCLK->STATUS.bit.SYNCBUSY); This should allow the WDT to simply connect to GCLK2, which has already been configured by the RTCZero library for the external crystal XOSC32K clock source."