RTC on Mx51 BBG randomly resets to 1-1-1970 - is it the PMIC? Is there a Fix or Work-around?

[mbp]

HELP!!   :smileyshocked:

On our variant of the i.Mx51 BBG and on the EVK the date & time (RTC) is randomly reset back to 1-1-1970.  Sometimes only the time is reset/changed - other times the time & date are reset.  This is obviously a critical issue when interacting with the outside world.  The EVK and our design uses the MC13892 PMIC.

I understand there may be irrecoverable PMIC RTC issues that result in RTC reset.  If this is true or not, Please confirm.  And provide any Work-arounds which may be employed.

Thank all,

mike

PS I have seen some MX53 and WinCE tweaks - but so far none applicable to this platform.

[YixingKong]

Mike

I do not see your response for David Dicarlo. Are you done with the issue?

Thanks,

Yixing

[mbp]

We see the intermittent issue on M77X marked parts as well.

We are considering a BBG-based platform update to an Mx6-SABRE platform-based design.   This would obviously terminate this issue (assuming nothing similar is present on Mx6 SABRE-platform designs).

Please post link to all issues (whether open or resolved) on the Mx6 SABRE platform running Android.  To help determine this development path.

Thanks,

mike

[daiane_angolini]

I don´t fully understand what you mean by "all issues on mx6 SABRE". If I understood it, this is not something public. And in case it is, it´s a matter of a community search.

However, if you are looking for the errata PDF file, you may find under freescale.com

karinavalencia, when Mike reply, please assist him on how to get the information he needs, as I think it´s not something Apps team would be able to help.

[mbp]

Daiane,

Would much appreciate a link to the latest HW/SW/FW erratta for the Mx6 SABRE Platform - running the latest Android release supported on this platform.

Thanks Daiane/Karina,

mike

[daiane_angolini · Accepted solution]

We have errata for the chip, not for the releases.

What we have for the releases (each release) is the release notes, inside it you will find a list of known issues at the release date (it does not include any bug found after the release date).

the errata for imx6 you may know, but, in case you don´t:

http://cache.freescale.com/files/32bit/doc/errata/IMX6DQCE.pdf?fasp=1&WT_TYPE=Errata&WT_VENDOR=FREES...

you can find more important document

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q&fpsp=1&tab=Documentation_Tab

[david_dicarlo]

Mike-

Before proceeding any further, please provide the MX51 part markings for all the boards that are exhibiting this issue.

Are there any new devices from current production exhibiting this issue or is it only seen on older boards, namely the EVK and Babbage boards? The Babbage board DaianeAngolini is using has a PC part from 2009 on it, make with an obsolete maskset (M90V vs. 1M77X production maskset).

[JorgeRama_rezRi]

Hi Mike,

These are some suggestions I have on top of mind to start debugging:

If you are using MX51 RTC:

- Check errata ENGcm10272

- Try using PMIC RTC

If you are using PMIC RTC:

- Monitor VSRTC voltage and make sure it is stable at all times.

- Monitor CLK32KMCU and make sure it is stable at all times.

- Do you have the BBG and EVK boards version that have the 10M resistor in paralell with the PMIC 32K crystal? This is necessary for clock stability.

Best regards.

Jorge.

[mbp]

the android_def_config indicates;

#

# on-CPU RTC drivers

#

# CONFIG_RTC_MXC is not set

# CONFIG_RTC_DRV_MXC_V2 is not set

# CONFIG_RTC_DRV_IMXDI is not set

CONFIG_RTC_MC13892=y

CONFIG_DMADEVICES=y

Can I simply switch the kernel to use the MXC and perhaps that may resolve this intermittent issue?

Oddly I see from another response the following;  (which doesn't coincide with the def_config).  Adding further confusion.

https://community.freescale.com/inbox?objectType=102&objectID=95608

Qingrong Jiang (to MIKE PETERSEN)1 week ago

Hi Mike,

This patch only for WINCE6. In Android we use the MX51 internal RTC.

I will review voltages - again.  Any additional thoughts?

[YixingKong]

Mike

Had your issue got resolved? If yes, we are going to close the discussion in 3 days. If you still need help, please feel

free to reply with an update to this discussion.

Thanks,
Yixing

[mbp]

No this issue is not resolved - from the analysis it appears there is a bug inherent in the PMIC and therefore this is un-fixable.

Please confirm.

mike

[daiane_angolini]

Hi, it´s not clear to me which kernel version are you using, would you mind to share this info?

Until JorgeRama_rezRivero work to figure out if any hardware erratum/rework is needed, we can double check the software side, what do you think?

[mbp]

Sorry for the delayed response.

This occurs with the Kernels associated with both R9.2 and R10.4 which is 2.6.31 and 2.6.35 respectively. 

This is a CRITICAL issue as date & time loss impacts networking, email accounts and any records or logs created by the system (as they get randomly tagged with incorrect date & time).

I will monitor more closely if you have any further questions.

Thanks!!

[daiane_angolini]

Ok, How can I reprocude the same error over here!? I have access to a imx51 BBG board.

Was you able to detect what is the cause of the date/time reset? I mean, what is the missing operation that makes the date/time to be reset?

[mbp]

It appears to occur most frequently upon power-cycling (obviously upon power up!  ...can't tell if it's spanked when powered down ;).  Most often both the Date & Time are fully reset to all 0's (1/1/1970) but I have also noted only a time offset - no change in date.  Which seems like it might bea clue.

I would guess that it could take 1:50 to 1:100 cycles to suddenly appear - when I try to trigger a loss, it never seems to occur - so I go about my business then next power-up (perhaps after the week-end) it's incorrect.

[JorgeRama_rezRi]

Hi Mike,

From your latest info, I assume the application uses the PMIC RTC, right? If so, I'll still be needing the following info in order to determine if it's a HW issue and find a possible fix:

- Monitor VSRTC voltage and make sure it is stable at all times.

- Monitor CLK32KMCU and make sure it is stable at all times.

- From your last message, I understand you haven't been able to reproduce the issue in the MX51 EVK. Is this correct?

- Do you have the BBG and EVK boards version that have the 10M resistor in paralell with the PMIC 32K crystal? This is necessary for clock stability.

- You mentioned the issue happens with kernel versions 2.6.31 and 2.6.35. Have you identified a kernel version that doesn't show the problem?

Best regards.

Jorge.

[mbp]

Q: Monitor VSRTC voltage and make sure it is stable at all times.

A:  YES - the VSRTC is stable at all times.

Q: Monitor CLK32KMCU and make sure it is stable at all times.

A: there is no access point on the PCB to monitor this clock.  The CLK32KMCU signal runs from the PMIC-BGA via internal layer to the Mx51-BGA!   ...any alternatives/suggestions?

The 32k clock was monitored at the crystal and varied between 75mV when powered-down to 250mV when powered-up.  No discontinuities were noted during power cycling.

Q: From your last message, I understand you haven't been able to reproduce the issue in the MX51 EVK. Is this correct?

A: YES, and I believe DaianeAngolini did as well (note earlier reply in this thread).

Q: Do you have the BBG and EVK boards version that have the 10M resistor in paralell with the PMIC 32K crystal? This is necessary for clock stability.

A: YES - we have the 10M resistor in parallel with the crystal.

Q: You mentioned the issue happens with kernel versions 2.6.31 and 2.6.35. Have you identified a kernel version that doesn't show the problem?

A: YES - The issue occurs equally on 2.6.31 AND 2.6.35 Kernel release(s).

>> From our understanding the operation is as follows; the PMIC monitors UVDET, when this drops below the 1.8V threshold, then the PMIC switches to the LiCell Voltage to maintain the RTC.  We noted that our LiCell Voltage varies from 3 to 3.4V during power-up (and the reverse in power-down).  However, the spec defines an acceptable range of 2 to 3.6V so this should not be an issue (per the datasheet).

This continues to be a CRITICAL ISSUE - your help in resolving this issue this MUCH APPRECIATED!

Mike

[YixingKong]

Mike

What is status of yur issue? Has it got rsolved or need frther help?

Thanks,

Yixing

[mbp]

We have given steps to reproduce:  Simply powercycle the BBG/EVK and note intermittent time or date&time loss/corruption.  Random occurrence; Could happen 1:20 or 1:1000.

Will review Errata again for possible implications.

thanks,

mike

[YixingKong]

Mike

How is the progress? DO you need furthe help? Please let us know your status?

Thanks,

Yixing

[mbp]

I have never received indication that anyone has been Able or Unable (or even tried) to reproduce this issue on the BBD/EVK?  Is this correct?  It has been heavily tested - power-cycled, boot-cycled and a time loss/corruption has Never occurred?

Thanks.

mike