K60 Microcontroller, its RTC, and MQX - Query

[kaitav]

Hi everyone,

We are using K60 microcontroller and MQX RTOS in our product and recently we faced a problem related to the RTC module. There are two cases and questions, explained below:

1) VBAT is powered by a coin cell battery: In this case the VBAT remains powered even if system is powered down. When we power the board, we see that the microcontroller gains control in around 32ms. We checked this by toggling a GPIO pin in the main function. The controller starts toggling the pin ~32ms after the reset pin goes high. What could be the reason for controller to take this much time? Could it be MQX? I want to know the average boot up time of K60 with basic MQX code running.

2) VBAT is powered by 3.3V used to power the K60: In this case NO battery is used. So every time the boards boots up, the K60 and its RTC module get their power supply from the same 3.3V source. I found from the manual that in this case the RTC module's POR will come in picture each time the boards is powered down and powered up. But the manual also mentions that this POR is only for RTC module and it does not affect system reset. However, when we did the experiment mentioned in above case, we observed that it takes around 532ms for the GPIO to toggle! That's 500ms additional delay. I am not able to understand the reason, but suspect that there could be some relation between MQX and RTC. What can be done to verify and solve this issue?

I have attached the waveforms of both cases.

Waveform Legends:

Orange: 3.3V power supply

Purple: Reset pin

Green: GPIO pin

Please let me know if you need more details.

Thanks,

Kaitav

[kaitav]

We checked the issue again with RTC enabled in MQX (RTCDEV=1) but not initialized in the main program. The reason for "why 530ms"? is still not much clear to us, but we did a power sequence to know more.

The power sequence is attached. We are first applying:

(1st cycle-State 0) 3.3V to VBAT pin -> (2nd cycle-State 1) introducing 5V (for 5V to 3.3V LDO) to generate uC's 3.3V -> (3rd cycle-State 2) continuing 3.3V and removing 5V -> (4th cycle-State 3) continuing 3.3V and again introducing 5V. We have selected the time as 4secs for each cycle at random.

The observation is that the first time VBAT gets power, the VBAT POR will be generated, so during the first two cycles we are getting approximately 500ms delay in GPIO toggling for the reason unknown. However, during the 3rd and 4th cycle, VBAT is continuously powered, but the reset of uC power might be clearing some RTC fault, so in this case we are getting ~30ms time.

It is now understood that in the first case VBAT POR will be asserted so we are getting some delay, and also that we don't get 500ms delay in subsequent cycles where 5V may be powered off to on but VBAT is continuously powered.

The exact reason for "500ms" still remains unknown. It could be RTC fault time, some POR delay, interrupt related, etc. but we are not sure.

[egoodii]

I would put some GPIO strobes around that above-mentioned MQX _rtc_init code as a means to see if that is a cause.

[kaitav]

Yes, good suggestion. But I think we are not going further with this exercise for now.

I checked with my colleague and here also the rtc init routine is the same, with 125ms osc stabilization delay. I guess the remaining is accounted by something else in that routine only; maybe interrupt or something.

Actually, this issue will come into picture only if VBAT is not continuously powered. And even for the case when it is continuously powered, the 500ms delay will happen only for the first time the board is boots up. All subsequent power up iterations of the board will have just around 30ms or so, depending on what's in the code.

Thanks for your help.

Kaitav

[egoodii]

While I can't comment on MQX startup time in general, I can tell you that the 'extra time' in the 'no battery' mode is because at some point there is an RTC init, and in that init is a check for RTC_TIF, indicating a 32KHz oscillator startup time is required, and this extra wait is inserted to give that time to finish, within RTC Init.

[kaitav]

Hi Earl,

Thanks for your suggestion. I will check that and get back with the observation.

But isn't 500 ms too much for even the oscillator startup time?

EDIT: I just checked with my colleague who is handling the software and he said that RTC is not even initialized. There is only a basic LED toggling code in the main and the delay that we are observing happens before the main starts, that is the before microcontroller takes the control of the GPIO. Thus we suspect it could be related to MQX, and in that something related to RTC.

Thanks,

Kaitav

[egoodii]

A 32KHz 'watch crystal' low power oscillator is inherently high impedance and low gain, and yes, full oscillator stability takes 'hundreds' of milliseconds.

So in the MQX I have installed, krtc.c, _rtc_init, is this block:

            if( !(rtc->SR & RTC_SR_TCE_MASK) || !(rtc->CR & RTC_CR_OSCE_MASK) )

            {

                rtc->CR |= RTC_CR_OSCE_MASK;

                /* recommended 125 ms delay for oscillator start */

                _rtc_wait_ms(125);

                rtc->SR |= RTC_SR_TCE_MASK;

            }

Granted, that only mentions 125ms, but YMMV.

[kaitav]

Hi Earl,

Thanks for your suggestion.

We found the problem. The 500ms delay was eliminated straightaway when we disabled RTC in the MQX library file (RTCDEV = 0). So with RTC not used at all, the start up time is ~30ms in both, with and without battery, cases. Now we have to analyze it and find a solution where RTC is enabled AND initialized in the code. Probably then your suggestion might help. I'll get back when we have got hold of this.

Thanks,

Kaitav