TM4C129ENCPDT: RTC Clock source Changed, and RTC functioning Stopped

Dear Charless,

Thanks for your feedback.

In our understanding, the HIBERNATE_OSC_HIGHDRIVE is set when 24pf Capacitor is used while connecting external 32.768Khz Crystal. Setting this HIBERNATE_OSC_HIGHDRIVE bit, should not bypass the internal 32kHz oscillator. Internal 32.768KHz oscillator should be bypassed (OSCBYP=1) only when single-ended oscillator is attached to XOSC0 pin. In our design, we use external 32.678 KHz Crystal with 24pf load capacitor (not Single ended external Oscillator). So, in the software, HIBERNATE_OSC_HIGHDRIVE is set, HIBERNATE_OSC_DISABLE should not be set (OSCBYP=0). Hence we have not set OSCBYP to 1 in the software. But this bit OSCBYP is set to 1 automatically. We don't know the cause for this automatic changing of this BIT to 1.

Could you please suggest for the possible causes.

There are four such instances out of around 400 units installed in the Field.

Thanks

Ettickkan

Hi Ettickkan,

  I think you might be confused with the LFIOSC (low frequency internal OSC). When OSCBYP is 1 it is to bypass the internal LFIOSC, not the oscillator that works with the external crystal. 

As I also showed in my reply, now pasting again below, if you look at how the driverlib is implementing the HibernateClockConfig(HIBERNATE_OSC_HIGHDRIVE) the OSCBYP will be set to 1.

Please also check the two errata I showed in my first reply. 

Hi Ettickkan,
I have not heard back from you. I hope it is clear to about the OSCBYP setting. I will close the thread for now. If you have new question you can open a new thread or if you have some updates to share you can just reply back to this post.

Dear Charles

Thanks for your reply and sorry for my late response.

Your explanation is clear and understood that OSCBYP is set to 1 to bypass the internal LFIOSC and also the explanation in Table 7.2

But my question is in the second part of your answer.

When we call the driverlib using the function HibernateClockConfig(HIBERNATE_OSC_HIGHDRIVE) OSCBYP will be not be set to 1. Only OSCDRV bit will be sent to 1 as we pass the parmeter to that function.

The below lines of codes, you had mentioned in your reply is to mask the relevant bits in HIBCTL register, so that other bits in that register is not affected by our write request sent through ui32Config parameter.

//
// Clear the current configuration bits.
//
ui32HIBCtl &= ~(HIBERNATE_OSC_HIGHDRIVE | HIBERNATE_OSC_LOWDRIVE |
HIBERNATE_OSC_LFIOSC | HIBERNATE_OSC_DISABLE);
//
// Set the new configuration bits.
//
ui32HIBCtl |= ui32Config & (HIBERNATE_OSC_HIGHDRIVE |
HIBERNATE_OSC_LOWDRIVE |
HIBERNATE_OSC_LFIOSC |
HIBERNATE_OSC_DISABLE);

I am not clear, how the above two lines of code can make OSCBYP bit to 1. (& Operator is provided to mask the required bit)

Our intention is not to set OSCBYP bit. We need to prevent that is getting set to 1 automatically.

Thanks for your understanding and support.

Regards

Ettickkan

Hi Ettickkan,
Sorry, I missed your reply. I re-evaluated the code again and you are correct that the OSCBYP should not be set if you only call HibernateClockConfig(HIBERNATE_OSC_HIGHDRIVE). You are using an external crystal and the internal oscillator should NOT be bypassed. I'm very sorry for the confusion.

Did you have a chance to evaluate if your problem is due to the errata HIB#19?

Hi Charles

Thanks for your feedback.

Once OSCBYP is set, software is infinitely waiting for Write Complete Bit in _HibernateWriteComplete(). This behavior is expected and repeats every time during

power on. Hence we thought that the software reset suggested in HIB#19? may not help us to resolve our issue.

We need to address the reason for automatic setting of OSCBYPbit (not set by software). Please suggest the possible reasons. 

Thanks and regards

Ettickkan

Hi Ettickkan,

  I cannot understand why the OSCBYP is set by itself unless it is written by the software. Have you tried the HIB#19 workaround and prove that it is not working?

Hi Charless

As mentioned already, since it is a repeat failure once the problem occurs, we did not try the solution suggested in HIB#19?

Also it is very difficult to simulate the occurrence condition as it is rare and random.

Do you feel, that it would be better to implement.  Please suggest.

Can you invite other experts like you to get involved for this issue and help us out.

thanks for your support.

Regards

Ettickkan

Hi Ettickkan,

  

Ettickkan E said:

Also it is very difficult to simulate the occurrence condition as it is rare and random.

Can you answer a few questions?

 1. The problem is intermittent, random, correct?

 2. How long does it take to see the problem after each power cycle?

 3. How long are these 4 units on the field before they are returned?

  4. Is it possible for you to swap one of the 4 returned units into other good boards you have. Can you still reproduce the same issue? This is to make sure it is not a board related problem. 

Yes, I strongly recommend that you implement the HIB19 workaround and prove that it either works or not works. If the workaround does not work, then it is possible a hardware problem (i.e. damaged MCU)

Hi Charles

Thanks for your feedback

For more clarity, please find below the overview of the issue.

In one of our products to textile industries, we are using TM4C129 MCU and we use external Crystal 32.768Khz with 22pf load capacitance for RTC function using Hibernation module. VBAT is driven with 3.6V 60mAh Battery. In the software, initialization module, the OSCBYP is not set

We have installed around 400 units in the field. After working for few months, in some of the units (around 6 nos), the OSCBYP bit is set  to 1 unintentionally and the software is infinitely waiting in the loop while(!(HWREG(HIB_CTL) & HIB_CTL_WRC)) as we don't use the external clock to drive Hibernation/RTC module.

The portion of the code in TI library where the software is entering infinite loop is below.

//*****************************************************************************

static void
_HibernateWriteComplete(void)
{
//
// Spin until the write complete bit is set.
//
while(!(HWREG(HIB_CTL) & HIB_CTL_WRC))
{
}
}

Once the problem occurred in that particular unit, every power-off->on cycle enters into this infinite loop and the normal functioning is not happening.

After we remove the Battery supply to VBAT pin of TM4C129 MCU, the OSCBYP bit is cleared and the unit becomes normal and it continue to work normal.

Hence it is not a hardware or MCU failure.

Please find my answers to your questions

Question 1. The problem is intermittent, random, correct?

Answer : The problem is not intermittent, not random.  The units are working for some months and in a rare case, this OSCBYP is set and software is entering infinite loop as mentioned above.  The occurrence of problem is rare (in few units and after working for few-weeks to few months), but it repeats every time once the problem occurred

Question 2. How long does it take to see the problem after each power cycle?

Answer : Once the problem occurred, the problem is seen on every power-on

Question 3. How long are these 4 units on the field before they are returned?

Answer : Some units Few weeks and some units were in field for few months

Question 4. Is it possible for you to swap one of the 4 returned units into other good boards you have. Can you still reproduce the same issue? This is to make sure it is not a board related problem

Answer : We have not done this swapping. As other units are working fine in field for so many months, replacing the board will solve this issue. But as mentioned above, there is no hardware failure in this problematic board. Removing battery power and connecting the battery again solves the issue. We need to understand the reason for the occurrence of this issue so that it can be prevented.

We need to understand the reason for OSCBYP bit getting set to 1 unintentionally. 

Thanks for your continued support

Regards

Ettickkan

Hi Ettickkan,

  Thank you for clarifying the questions I have. I understand you wanted to know the reason why the OSCBYP is set unintentionally, I just don't have a good answer as to why the OSCBYP bit is set by itself.  Do you see any other register bits in the Hibernation module not retaining their states when the OSCBPY is set? What I can think of is that the OSCBYP is a register bit residing in the Hibernation module which is powered by the Vbat. I can image a register bit to flip its state when its operating condition is out of spec.

Do you think you have a stable Vbat supply?

Do you have the recommended RC filter on the Vbat?

Any possible noise on the supply?

Earlier I also mentioned about errata ELEC#2. Can you please also check if your VDD ramp up time is faster 0.7V/us?

The reason why I'm trying to connect dots between OSCBYP and the Vbat is because you mentioned that the MCU is acting normal until the problem occurred. After the problem occurred, you can get it back to normal by first removing the battery and then connect back the battery. 

Can you use the scope to monitor the Vbat and compare between the board that is normal against the board that starts to have OSCBYP set?