SAMD20 and DFLL48 with external 32k crystal: fine lock sometime isn't reached

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a custom board with SAMD20 MCU with external 32kHz crystal connected to XOSC32k (PA00 and PA01).

I'm using Atmel Software Framework code (3.45) for clock initialization. I edited conf_clocks.h to use the external 32kHz crystal to feed DFLL48 to have 48MHz clock. It works well most of the time.

 

Unfortunately I noticed that the MCU sometime hangs. It happens specially if I play with the power supply (power down and up). It doesn't happen frequently, it's difficult to reproduce the problem (I connected a microswitch to power down the board and I have to press the switch many times). It seems this happens if I cut the power for 3-5s. If I simply reset the device with reset input pin, the MCU restart and doesn't stop anymore.

 

After some debugging I found the loop where the MCU hangs:

while(!system_clock_source_is_ready(SYSTEM_CLOCK_SOURCE_DFLL));

This loops waits for DFLLLCKC, DFLLLCKF and DFLLRDY bit flag. The problematic bit is fine lock (DFLLLCKF). When the problem happens, it seems this lock bit never set. I can stop the code with the debugger and run it again, but the lock bit stays zero.

 

I think I can solve this problem with watchdog (that I now configure after clock initialization). However I'd like to solve it in a better way. Do you have any suggestions?

Attachment(s): 

Last Edited: Fri. Mar 1, 2019 - 11:58 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No suggestions, I used the watchdog hammer to fix it, only costs a quarter of a second at boot time. 

See link

Jerry

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting I'm not the only one that encountered this problem. Atmel/Microchip guys should reply and give an official answer.

 

I don't know your point of view, but this is a very big critical issue, because when it happens, it hangs the MCU forever!!! We are using official ASF libraries, so the problem is a bug in the code or in the hw inside MCU and the code needs a workaround (another errata).

 

Have you looked at the code generated from Atmel Start? Maybe there they improve something.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried with Atmel Start too that generates a completely different code from Atmel Software Framework. However the problem appears again.

 

Of course I'm using a custom board, I don't know if this bug appears only on my board or it's a bug inside the MCU.