Forums

AL,

Since the reset is triggered by SVSH, it's a proof that VCC has fell below the thereshold voltage. The SVSH was set to 0x0 which only trigger a POR if the threshold is below 1.8V but we have seen your scope shot indicates VCC is well above 1.8V. Where are you probing the VCC? Are you probing directly to the VCC pin on the MSP430? Any circuitry on your custom board that might pull the VCC down?

Can you disable the SVSH to see if the reset still exist just to eliminate the PMM factor from the 10 ms ramp up.

Also, can you clear the SYSRSTIV reg by writing a value to it after POR since the BOR flag may exist due to intial power up.

Again, we need to reproduce the results to see if it is a hardware issue.

We are probing DVCC as close to the chip as practical. There are no components between the probe and the pin, only PCB trace.

Here are a few more pictures.

1-- no reset. I can't explain why Vcore drops first and then rises, but it could have to do with MSP430 activity, indicated by the noise on DVCC.

The low point on the DVCC trace is 2.25V.

2 -- reset occurs. Notice that Vcore does NOT drop. Also notice the lack of MSP430 activity until after the spike in Vcore.

low point of DVCC is 2.4V.

3-- Response to a different interrupt input, which is faster. Notice that DVCC is flat until it rises, and the MSP430 stays relatively idle until then.

Vcore still drops before rising later on.  No reset occurred.

Regarding image #2 in the last post, it seems to be fairly common for the ON DET signal to be "kinked" like that when a reset occurs. I propose that the cause of this is that for some reason that pin on the MSP430 is becoming an output and is trying to drive the signal to ground. Al is checking whether the firmware ever does that, but it shouldn't; so if it is happening the explanation must be something endemic to the MSP430.

Another consequence, if true, is that whatever is happening does so before the VCC upward ramp.

Hi,

Can you describe the steps followed before going to LPM and after waking up? And based on your description, you have PMMCOREV=0 and SVS/SVH level 0, but you also mentioned that you are changing the level in some cases, is that correct? Changing the PMMCOREV would also change the SVS/SVH levels.

When the device is in LPM, the Vcore is slightly higher (~40mV). In the non-Reset cases, it would seem like the device is in LPM, then wakes up (VCore goes down), then, do you change PMMCOREV?

On the reset case, it would seem like the VCore spikes and that is an abnormal case. What I don't know, is if this happens after the device wakes up or not. Is there any way you can plot the MCLK?

Also, from all PMM sources, what do you have forcing a reset and what forces an interrupt? Do you get any SVM interrupts at all?

Finally, do you have any Rev F samples available to see if this problem is related to the existing bugs? And, can you try updating the Core Libraries? Since the first release of the Core Libraries we have found/fix some bugs and we also implemented workaround for some errata.

I'm sorry I'm asking for so much stuff and I'm not providing clear answers but this problem is unknown to me and since I can't replicate it on my bench, I'm trying to understand what is happening.

Regards,

Luis R

My update for today....

Luis RC

When the device is in LPM, the Vcore is slightly higher (~40mV). In the non-Reset cases, it would seem like the device is in LPM, then wakes up (VCore goes down), then, do you change PMMCOREV?

This is helpful since it explains why Vcore always drops during a normal wake-up. We were puzzled by that. I believe Al can confirm that sometime after the wake-up he raises the Vcore voltage, so that explains the subsequent rise. It also indicates that when a reset occurs, the MSP430 never comes out of low power mode, since we would see Vcore drop (and we don't). Furthermore, it explains the lack of activity-related noise on DVCC (since the MSP430 is still asleep).

Here are a couple of new pictures, with a very narrow time slice. First the no-reset case:

Notice MSP430-generated switching noise on the supplies from the beginning of the frame.

Next, the reset case:

Notice the complete lack of MSP430 activity.

I'mm copying post #7.

I haven't updated the libraries yet but I can try that. We have been using the August 2010 release.

I think the normal drop in Vcore is when we exit LPM3 and start the DCO/FLL. Vcore is then set to PMMCOREV_1.

In the reset case with Vcore spiking, I would guess that is when it goes into reset since I believe the power-on condition is PMMCOREV_3.

I don't believe I get SVM resets at all.

These are the details on SYSRSTIV that I was able to capture:

Sometimes SYSRSTIV=0x000E, and others it is SYSRSTIV=0x0002 (BOR).

SVSMHCTL,SVSMLCTL,SVSMIO=(0x4400,0x4400,0x0020)

I had one questions from earlier:

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?

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.

Daniel,

I don't believe the ON_DET is being affected by the MSP430.

In Image #2 you see the DVcc drop is more pronounced and the DVcc drop is happening at the same time sa the ON_DET kink, but long before Vcore changes..

Al

Additionally, I often see the "kinks" occur even when there is no reset. It seems that the odd waveform is the result of bounce in the contacts I am manipulating to generate the interrupt on ON DET, and is probably a red herring regarding the resetting.

AL,

Just tring to eliminate some variables for our debugging purpose. Can you try the following and see if reset still exist? Thanks.

1. disable SVSh and SVSm

2. do not switch the VCC (use the same voltage source) all the way through

3. 1 & 2 together.

We now have MCLK visible at a pin. Its behavior changes depending upon whether reset occurred.

With no reset, MCLK follows VCC until it starts clocking:

with reset, MCLK first drops to 0 before finally starting to clock, some time later than normal.

Jason Qian

Can you try the following and see if reset still exist? Thanks.

2. do not switch the VCC (use the same voltage source) all the way through

In our design, a digital signal passes through some analog circuitry to activate the "high power" VCC regulators. When I place a DC on the input to that network (to keep VCC high all the time), I have not observed a reset event. However, I can make a reset occur simply by asserting the DC input (without forcing any of the interrupt lines).

Daniel,

Can you please send the schematic of your customized board to us to take a look?

Just curious how are you controlling the switching between the power supply? Using the Det_on signal?

I talked to Al today and he mentioned he will try to recreate the issue with a TI evaluation board.