Forums

 Hi

Daniel Cross

One of the first actions should be to assert the PWR ON signal, but it does not occur on time due to the reset.

 Hi Daniel, did you checked this is not a problem due to WATCHDOG?

 If not anyway it is not a good practice to drive digital line with analog signals, the better solution is to use analog comparator to check signal passed threshold.

 Regards

 Roberto

There could be an issue with the watchdog timer expiring at the same time that the interrupt occurs. I would think that would be a rare occurrence, however.

The analog comparator uses too much current. The point of LPM0 is to use as little as possible in standby.

Thanks.

Hi Daniel,

Please see below for comments from our factory expert. Could you please provide some scope shots of RESET, TEST, VCC and Vcore? Thanks.

One thing that could explain part of the behavior is that the MSP430 has clamping diodes in GPIOs so it can actually get powered from them even when there’s no DVCC. Perhaps, the MSP430 is starting at some point of the ON_DET curve before DVCC is ready and that causes some problem with the circuitry? Perhaps that explains the drop in Vcc at the beginning since the MCU is getting powered before VCC is ready.

Another thing to check is the VCC vs MCLK. As you know the maximum MCLK frequency depends on VCC, so is it possible that they are changing MCLK using DCO/FLL before the voltage has settled?

If this is the behavior of their hardware, perhaps they can add a delay at the beginning and see if that makes the problem disappear.

If the problem persists, I think it would help to get some o-scope shots of RESET, TEST, VCC, VCore and if setting PWR_ON is not the first thing they do in SW, can they toggle something right at the beginning of the code?

RESET tracks DVCC. Vcore looks different, but doesn't droop appreciably.

First, the no reset case:

Then, the reset case:

For clarification, we are in LPM3 when we are awakened by an interrupt on the input.

We are currently using the August 2010 release of the Core Libraries described in slaa448. I noticed there was an 11/11 release but I haven't updated to that release.

All Vcore switching operations are performed using the core library function calls.

We leave SVSx and SVMx enabled and are always in normal performance mode.

The maximum MCLK frequency never goes above 8 MHz.

Before entering LPM3, our state is:

1. We are using an external 32 kHz clock. MCLK and SMCLK setup to 2^15*2^4 clock using the Init_FLL_Settle() function in the core library (32x multiplier, using DCOCLKDIV output). This works out to about 512kHz.
   Most modules are disabled and they are sourced using ACLK to prevent any other clock requests from being enabled.
2. SVSx and SVMx are enabled. We always stay in normal performance mode, and never enter fast switching mode.
3. We are in Vcore=PMMCOREV_0 while in LPM3.
4. Most I/O are configured as GPIO and driven low. Several I/O are inputs and PERI as required (i.e. XT1 are peri to support external clock, PWR_ON is input with interrupt enabled to support wakeup).
5. The WDT is set as an interval timer so we can awaken periodically.

We are awakened from LPM3 by the assertion on PWR_ON. 

1. The I/O are configured as required for the operation.
2. VCore is set to PMMCOREV_1 and the clocks are re-configured:
   2a. We use an external clock input on XT2, (not an external clock). The frequency is safely under 8 MHz.
   2b. MCLK and SMCLK are sourced from XT2.
   2c. ACLK remains sourced from XT1.
3. The required modules are re-initialized.
4. The WDT is set back as a watchdog. Our timeout is 1 sec.

I had one question about items in the device errata:

1. I noticed that PMM17 is only relevant for some lot numbers. Is it OK to use the prolongation code in the snippet regardless of the rev and lot of the silicon?

Clarification:

We wake up from LPM3 using ON_DET, and we assert PWR_ON almost immediately after receiving the ISR on ON_DET.

Al, can you post the scope shot for Vcc during the toggling of the external pin. The Sys16 on errata mentioned that if there is an abrupt ramp of Vcc which may also cause the device to reset. 

The images above show Vcc rising.

I'll see if we have any scope shots with a smaller time scale.

However, as the attached scope probe shows, the same Vcc rise time with a fast ON_DET rise time doesn't seem to cause BOR.

Al

Here is a smaller timescale view of the no-reset case....

Hi Daniel, Hi Al,

We haven't seen this problem before and I would like to investigate it but whatever help you can give us to replicate the issue will be highly appreciated.

Can you replicate the problem in a TI board (target board, experimenter's board)? Do you have a code snippet?

Regards,

Luis R

Additionally,

Can you check the reset reason (SYSRSTIV)?

I tried to run some quick tests here using a GPIO with slow rise time to wake-up the MCU and couldn't replicate the problem. Any help you can provide will be very useful.

Regards,

Luis

Luis,

I don't have an example that will run on the demo board at this time.

The issue with easily getting SYSRSTIV is that if I run the board with the MSP430-FET, since it powers the device I do not see the resets.

I've tried setting the Vcc output from the MSP430-FET to lower voltages (in low-power our voltage is about 2.5V) but either my communication between my debugger and my target device gets lost or I still do not see the reset.

I could try saving SYSRSTIV to FLASH when inside _system_pre_init() and when the reset occurs use the debugger to peek the memory, but I haven't tried this yet.

I'll let you know if I can develop a test case or if I can captuer SYSRSTIV.

Al

Jason Qian

The Sys16 on errata mentioned that if there is an abrupt ramp of Vcc which may also cause the device to reset. 

Jason,

Can you tell if this VCC ramp is big enough or fast enough to cause the reset mentioned in SYS16?

Daniel,

The VCC ramp seems fine. As Luis mentioned, we need to reproduce the reset from our end to further investigate the issue.