SAML21 RTC SYNCBUSY Lock-up

[cburgess]

We've got a real head-scratcher with the SAML21 RTC peripheral at the moment.

It is only present on some of our boards - which leads us to think there may be a hardware influence

All we are doing is:

Set the SWRST bit in the CTRLA register to reset the peripheral

Wait until the SWRST bit clears in the SYNCBUSY register   - this stalls on the "bad" boards

RTC is using the external 32kHz crystal oscillator  - which we know is good because we are using the same clock for a timer and also the DFLL - we are getting the expected 48MHz

Clock configuration is:

   /* Turn on the digital interface clock */
   system_apb_clock_set_mask(SYSTEM_CLOCK_APB_APBA, MCLK_APBAMASK_RTC);

   /* Select RTC clock */
   OSC32KCTRL->RTCCTRL.reg = RTC_CLOCK_SELECTION_XOSC32K;

   /* Reset module to hardware defaults. */
   rtc_count_reset();

     
      ... we are locking-up in "rtc_count_reset" waiting for SYNCBUSY to clear


Any clues?

~ Carl ~

[ataradov]

Are you sure it is actually running? Do you see oscillations on the pins?

DFLL will keep on running even without reference clock. It won't be as accurate, but it will produce something close to 48 MHz.

[cburgess]

A bit more testing:

XOSC32 is running - this feeds GCLK1 which in turn drives TC2 - we see TC2 incrementing

Changed RTC to use RTC_CLOCK_SELECTION_ULP32K  - problem is still there.

Tried this:
RTC->MODE0.COMP.reg = 0xABCD;
while (RTC->MODE0.SYNCBUSY.reg)  { }   

This works (I can see the value in the debugger)  which implies the RTC is getting a clock

then:
   
   RTC->MODE0.CTRLA.reg = RTC_MODE0_CTRLA_SWRST;
       while (RTC->MODE0.SYNCBUSY.reg)  { }   

- The previously written COMP register is now zero, but we get stuck in the SYNCBUSY test...
- Also the SWRST bit in CTRLA is stuck at '1'

[ataradov]

In cases like this I just create the simplest application I can that still reproduces the issue. Start with the default clock for the GCLK0 and not enabling any other clock sources or peripherals.

There are too many things that can potentially go wrong. One thing to check for sure is that you are setting PL value correct.

[cburgess]

OK

PLCFG = 2  - so we were running at PL2 and enabled.

Running GCLK0 with OSC16M and the problem goes away.

I think we may be homing in on the problem

[ataradov]

And just double checking - you have flash wait states (RWS) set correctly as well? It should not lead to locks like this, but worth checking anyway.

Try running from the DFLL, but use OSCULP32K as a reference for the FDLL.

And still, check that the crystal oscillator is actually running. Either by observing the XIN/XOUT pins or by connecting it to one if the GCLK_IO [ x ] pins.

[cburgess]

We're running with 2 wait states :  system_flash_set_waitstates(2);  - confirmed by inspecting NVMCTRL->CTRLB

Managed to get GCLK1 (XOSC32) onto PA15 - 'scope showing 32.77kHz with σ = 4.46Hz, 47% duty cycle  - looks clean

Going to try OSCULP32K for the FDLL now

[cburgess]

Running with OSCULP32K for the DFLL made no difference.

I noticed that Table 46-6 Maximum Peripheral Clock Frequencies has the APBA clock frequency pegged at 6MHz for PL0 & PL2
when Clock domain = BACKUP

This change seems to have fixed it:

system_backup_clock_set_divider(SYSTEM_MAIN_CLOCK_DIV_8);

[ataradov]

Oh, yes, you need to respect maximum clock frequencies.