MSP430F6436: MSP430F6436 power supply freeze on start-up

HI Conor,

The 0.2Vpp is abnormal. Have you tried to use the internal REFO/VLO/DCO as the clock source and see if it still has the same issue. It can help us to know whether this issue is related to the external crystal. 

Best regards，

Cash Hao

Hi Cash Hao,

The situation has not yet been resolved by changing the oscillator. After narrowing down the cause, it was found that the RTC has stopped.

The RTC generates an interrupt (RT1PSIFG) every 0.5 seconds. If the power supply is turned off and on for 10 seconds and then turned on again, there is a high probability that the RTC will stop. Powering down and then powering up again after about 10 seconds causes the RTC to stop with high probability. The probability of it stopping is low if the power down time is short or if it is connected to the debugger.

Errata describes the RTC stack and it seems that the RTC does not work properly unless the VBAK voltage exceeds the threshold, so I tried a workaround, but the situation has not changed much. By monitoring the voltage on the VBAT pin from an oscilloscope, it was confirmed that the RTC initialisation process is carried out after the voltage has stabilised sufficiently at 3 V.

The LCD display of the RTC register values when a freeze occurs shows RTCCTL01=0x4000 (the value of RTCHOLD), even though the stop flag is released with RTCCTL01 &= ~RTCHOLD;.

As for the interrupt setting RTCPS1CTL, it holds the value as set and there is no problem, it seems to be due to RTCHOLD not being released, is there any event that prevents it from being released?

Thanks,

Conor

Hi Cash Hao,

Sorry, I gave you incorrect information. I confirmed that RTCHOLD has been released.
■Value of RTCCTL01
・When frozen: 0x2000
・Normal: 0x3001

Q1.
When it freezes, the counter seems to be stopped, so it seems that the clock is not being supplied properly. Is it correct to understand that there is no particular option for the RTC_B clock and that only an external clock is supplied?

Q2.
In the case of supplying only an external clock, I believe that the small clock amplitude is the cause. Is there anything I can do to prevent this?

Thanks,

Conor

Hi Conor,

Sorry for the late response, we are having a holiday here. 

Conor said:

Q1.
When it freezes, the counter seems to be stopped, so it seems that the clock is not being supplied properly. Is it correct to understand that there is no particular option for the RTC_B clock and that only an external clock is supplied?

Yes, this behavior seems related to the LFXT failure. And yes, the RTC_B module can only be source by the external crystal.

Conor said:

Q2.
In the case of supplying only an external clock, I believe that the small clock amplitude is the cause. Is there anything I can do to prevent this?

You can try with different load capacitance configuration. 

"The software-selectable XCAP bits configure the internally provided load capacitance for the XT1 crystal in LF mode. This capacitance can be selected as 2 pF, 6 pF, 9 pF, or 12 pF (typical). Additional external capacitors can be added if necessary."

For the detail information, you can refer to the UG chapter 5.2.4 XT1 Oscillator.

https://www.ti.com/lit/ug/slau208q/slau208q.pdf

Best regards,

Cash Hao

Hi Cash,

The capacitor was changed, but this did not have much effect on the amplitude. The oscillator waveform shows that it oscillates with an upper limit around 2.5 V and appears to be dependent on the 2.5 V AVCC rather than the 3 V DVCC.

Q1. As for the upper limit of the oscillator amplitude voltage, does it depend on the AVCC? Or is 2.5 V the upper limit due to other factors or specifications?

Q2. If the oscillator amplitude voltage depends on the AVCC, should the AVCC voltage be raised to DVCC when using the oscillator, or is there a possibility that the clock input may not respond due to the voltage threshold if the RTC is operating on the DVCC reference?

Q3. If the AVCC voltage needs to be increased, the 2.5 V reference voltage cannot be taken from the AVCC. In such a case, we would appreciate it if you could advise us on the recommended design of the analogue power supply when the DVCC is 3 V and the reference for the ADC, DAC and the external temperature sensor is 2.5 V.

Thanks,

Conor

Hi Conor,

I want to confirm that you supply 2.5V on the AVCC pin and 3V on the DVCC pin on your board, is my understanding correct?

Well, according to the device data sheet. It is not allowed that the difference between the AVCC and DVCC is larger than 0.3V. If you have done it, I would recommend to use the same source for both the AVCC and DVCC first, then replace with a new MCU for testing. 

Conor said:

Q1. As for the upper limit of the oscillator amplitude voltage, does it depend on the AVCC? Or is 2.5 V the upper limit due to other factors or specifications?

The oscillator is considered as analogy modules powering by the AVCC. 

Conor said:

Q3. If the AVCC voltage needs to be increased, the 2.5 V reference voltage cannot be taken from the AVCC. In such a case, we would appreciate it if you could advise us on the recommended design of the analogue power supply when the DVCC is 3 V and the reference for the ADC, DAC and the external temperature sensor is 2.5 V.

It is recommend to use both the AVCC and DVCC at 3V. 

And this MCU has REF module which can provide 1.5V, 2.0V and 2.5V internally for the ADC and DAC modules. 

You can refer to this example code which uses the internal reference voltage at 1.5V for temperature sensing. 

https://dev.ti.com/tirex/explore/node?node=A__AKIHnPHAa-mXgbbb-yq09A__msp430ware__IOGqZri__LATEST

Best regards,

Cash Hao

Hi Cash,

Change AVCC and DVCC to the same power source as recommended.
The freeze was not resolved when the AVCC and DVCC were verified with the same voltage. However, by disconnecting the VBAT wiring and setting it to OPEN, the problem was resolved. It is thought that the RTC probably stopped due to the poor voltage rise of the DVCC and VBAT in the following errata.

As there was no plan to run the RTC with VBAK and VBAT after power down, VBAK was connected to OPEN and VBAT to DVCC as the recommended unused terminal processing. I would like to know about the recommended connections when using the RTC from the above errata, as I thought it could cause a malfunction as VBAT is in an undefined state at OPEN and I would like to check.

Thanks,

Conor

Hi Conor,

According to the UG chapter 3.1, if there is no separate battery backup supply in the system, connect the VBAT pin to DVCC and set bit BAKDIS=1.

Best regards,

Cash Hao

Hi Cash,

I tried the recommended method for handling unused pins, but it still freezes. Currently, MCU seems possible to avoid freezing by connecting a strong low-pass filter to VBAT and working it so that it does not exceed DVCC. Could you please confirm whether this is the correct way to resolve the errata?

Thanks,

Conor

Hi Conor,

Add a low-pass filter looks like a possible solution for me to avoid this errata. Just for curious, what are the sources for the DVCC and VBAT on your board?

Why it would cause the the DVCC and VBAT crossing each other below 2V during power up. Have you used an oscilloscope to check on the DVCC and VBAT pins whether you can see the crossing there?

Best regards,

Cash Hao

Hi Cash,

Cash Hao11 said:

Add a low-pass filter looks like a possible solution for me to avoid this errata. Just for curious, what are the sources for the DVCC and VBAT on your board?

I am using LT3010EMS8E#PBF(ADI).

Cash Hao11 said:

Why it would cause the the DVCC and VBAT crossing each other below 2V during power up. Have you used an oscilloscope to check on the DVCC and VBAT pins whether you can see the crossing there?

I checked by inserting a 1kΩ resistor into DVCC and VBAT. The power supply voltage may drop once, and when it comes back up, VBAT seems to catch up with DVCC.
DVCC_VBAT_Cross Validation.xlsx

According to this errata, this occurs when the voltage crosses below 2V.
Is power-on reset at around 2.4V using the PMM function one way to deal with the problem?

Thanks,

Conor

Hi Conor,

A software BOR/POR reset should avoid this issue by setting the reset when DVCC and VBAT is stable over 2.4V. 

Best regards,

Cash Hao