[f4250] Strange timer behavior after exiting LPM4

Argail said:

I measure MCLK and is stable at the time the MCU is awake.

Are you saying that MCLK is stable (at the expected value) during the interval in which the problem happens? Are you using a digital scope to verify that?

Anyway, I'd expect the opposite problem, e.g. longer timings and not shorter ones. In fact the 32kHz crystal (are you using it?), which is the reference for DCO through FLL, can takes ages (hundreds of milliseconds) to start, so in the meanwhile the FLL slows down the DCO to the lowest tap trying to lock MCLK/(D×[N+1]) to ACLK (0 Hz).

To avoid that, you could disable the FLL, holding SCG0 to 1 after the interrupt end, until the crystal starts (you can detect this clearing, waiting for a while and then checking OFIFG in NMI ISR).

But if you can afford the ~1 uA of LPM3, stay with that and have fun!

Thanks for the reply,

The MCL is effectively stable at the frequency I want  (1Mhz) when the problem happens. I measured it with a 100Mhz oscilloscope and the full communication process with Saleae Logic tool.

I use the Crystal but after in the code. Receive an interruption on the antenna which wakes up the MCU, wait the end of the frame, reject the first frame and send "repeat" to the serve, receive the new frame and analyse it, this is done with the DCO. If it's a Wake up command, the quartz is started with the standard boot process (wait loop, ofifg, ...).

I enable the FLL only if the quartz is started, so during the procedure which presents a problem, the fll is disabled and MCU running only from DCO. BUT it is what I was thinking I do because I have disabled it by setting the SCFQ_M = 1, which disable the modulator, apparently not the FLL itself, right? Could this be a problem?

I'm on Week-end at that time, will try this on monday;)

Anyway, if the FLL is not running right, I should see the frequency beeing modified on the MCLK pin? But as you say the frequency should be lower, so the timing longer.

 THe timer_A is based on SMCLK not MCLK, and It's not possible to directly measure SMCLK, But it should be the same signal.

The correction I've made now is effectively to stay in LPM3, and the not debugged LPM4 mode for storage not accessible to the end-user.

Best regards

Argail said:

I have disabled it by setting the SCFQ_M = 1, which disable the modulator, apparently not the FLL itself, right? Could this be a problem?

Could be, but it isn't as you have verified that MCLK is stable when the problem happens.

Argail said:

THe timer_A is based on SMCLK not MCLK, and It's not possible to directly measure SMCLK, But it should be the same signal.

Right, SMCLK=MCLK on your MCU.

Regards,

Peppe

The so-called LPM4 means the CPU, the ACLK, the DCO, the DC generator are all shutdown. When you wake up from LPM4, first the DC generator has to be enabled so the DCO can start. Then the DCO is started. At the same time the ACLK is also started but it usually takes a long time to have a stable ACLK. After that, the DCO is adjusted by the FLL using ACLK as a reference. During all the above delays, your SMCLK is not stable and useless for the Timer to do any timing measurements.

Why do you go into LPM4? If you have to do it, then after exit from LPM4, you need to wait for ACLK and the FLL to stabilize.

I've made some other measurement and the MCLK effectively moves after wake-up from LPM4, do not understand why I didn't saw this behaviour before... anyway noob mistake:s

The frequency moves from 1 to 4Mhz in the breadboard (SSOP 4270), but slow down in the prototype around 640Hz (VQFN 4250). I understand that the frequency is slowing down because it tries to configures the frequency from ACLK which is randomly oscillating.

In the case I do not want to use the ACLK (nor the FLL+ therefore) at all even if it is mounted in the circuit how should I do that?

It seems I can't stop the ACLK by software, if I set OSCOFF simply nothing more happens.

Setting SCG0 or SCFQ_M or both seems not having any effects..

It is simply impossible to use the 4250 without any crystal?

(I wasn't there during the development, I only have to debug it, sorry if some subtleties escape me)

The FLL is disabled when the status register bit SCG0 = 1.

Software can disable LFXT1 by setting OSCOFF, but only if this signal is not used elsewhere.