MSP430F5437A set Vcore with PMM core lib

seb said:

so how is the CPU suppose to slow this setting down internally

This is not done automatically.

The PMMCOREV bits control the output voltage of the interla core voltage generator. Nothing more. Having them on the lowest settign and driving MCLK with a 25MHz crystal is as fatal as having them on the highest settign and applying a 50MHz crystal. Both will crash the cpu.

It is your job to know what core voltage you program and what external clock (or DCO clock) you use. If you fail to adjust the settings so that they match, things won't work.

However, MCLK and SMCLK have dividers, so you can set MCLK (which is the only critical clock) to 1/4 of the crystal/oscillator frequency while you lower the core voltage.

seb said:

everytime I saw my last settings in this register, can that somehow be, or is the MSP430 fooling me, and some Cs didn't completely dischargeor something like that.

According to the datasheet, a BOR (real power cycle or pullign RST) should reset PMMCOREV to default value. You really shouldn't see your old setting sin there. but perhaps teh debugger just didn't do an update of its buffered copy of the register?
Are are you perhaps running the code in simulator (so it doesn't actually run at all but is just simulated in the debugger) The simulator doesn't properly initialize all simulated hardware registers. And is of course not affected by a power cycle :)

Also, when you do a power cycle, the MSP will immediately start. The debugger will attach much later, when your code was perhaps already run, changing the value from default.

Hello,

Thank You Jens for your insight. First some answers to your points:

I do not think I am working in a simulator mode ( can I proof this somehow ) since I have a MSP430 UIF USB debugger attached to my PCB and on this PCB there is a LCD running with according settings ( and I can this changes see ) , so I think it could be that the debug mode is not updating the register settings, which of course is bad for my debugging, since I have to trust those values.

Anohter point now: my biggest Vcore level is 2, this means a maximum High frequency of 20 MHz is applied to the CPU internally ( while still there is a 25 MHz oscillator applied to XT2 ) . Now it seems to me, at leats my settings say I am using XT2 with divider 1 => 25 MHz as MCLK and SMCLK source. Regarding your insight, the MSP430 should somehow trip or fail to work ( I assume this might not happen, but statistically this should happen). In my case untill now, I never say something like this, and I definetly will see a POR PUC BOR in any cases because my LCD will then restart.

So I am still confused, what you say makes completly sense to me, although I just dont see it in reality in my MSP430.

Jens-Michael Gross said:

Having them on the lowest settign and driving MCLK with a 25MHz crystal is as fatal as having them on the highest settign and applying a 50MHz crystal. Both will crash the cpu.

I do not agree with this statement though, as the datasheet and or familyguide states that the higher Vcore levels dont affect lower frequencies but vice versa it does. So that is why I think my workaround can be to just put Vcore to the highest level and never touch it again, no matter with what frequency my CPU will run.

My next step will be to measure the frequency on one physical pin ( I thought of measuring it directly at my crystal, but I think the probe will affect the frequency, due to its capacitance ?! I will test it anyway ) , then I will update this post with the results.

What I would have expecetd was: a MCLK of 20 MHz while in lower Vcore, but settings of 25 MHz applied.

Thanks for reading.

Seb

seb said:

I do not think I am working in a simulator mode ( can I proof this somehow ) since I have a MSP430 UIF USB debugger attached to my PCB and on this PCB there is a LCD running with according settings ( and I can this changes see )

Well, okay, an LCD might be a good indicater. But we had cases where an old firmware caused the LED on the target to blink, while every change on this old code was just executed in the simulator, not changing the LED behaviour (obviously, but to the surprise of the user)

seb said:

my biggest Vcore level is 2, this means a maximum High frequency of 20 MHz is applied to the CPU internally

Not is, but is allowed to be. You may apply more, it is 100% under code control and there is no automatism preventign this happen. Just that if this happens, the MSP may crash.

seb said:

( I assume this might not happen, but statistically this should happen)

Right. There is no guarantee that it will fail. It is only not guaranteed that it will work :)
As soon as one of 1000 will fail (or maybe less), the datasheet will state that you must not use this to be on the safe side. Even if it might work for most devices.

seb said:

the datasheet and or familyguide states that the higher Vcore levels dont affect lower frequencies but vice versa it does.

Right. What IO meant is that 25MHz is as much too much for a lower PMMCOREV setting as 50MHz are for the highest. One setting (and the resulting core voltage) is only guaranteed to support a frequency up to a certain limit. The higher the settign, the higher the border frequency above which th elikelyhood of a crash exponentially increases.

seb said:

( I thought of measuring it directly at my crystal, but I think the probe will affect the frequency, due to its capacitance ?

Definitely. We just bought a $1000 probe for our scope (yes, just the probe!) that allows measurements directly on a crystal pin due to its extremely low capacitance of 0.5pF/10MOhm. It is somewhat clumsy, needs a power supply, but was worth the money. But such a thing is definitely beyond most peoples budget.

On almost every MSP, there is a way to output SMCLK and/or ACLK and sometimes even MCLK to a port pin for measurements. Usually, just the proper PxSEL and PxDIR bits need to be set.

seb said:

What I would have expecetd was: a MCLK of 20 MHz while in lower Vcore, but settings of 25 MHz applied.

No. There is no limiting mechanism. You apply what you apply and have to be sure to configure the PMM properly before you use it.

Actually, if the MSP would know about absolute frequencies (for comparison/limiting), it wouldn't need the crystal at all :)

So now to come back at some points.

I did meassure the voltage of Vcore and some clock settings on my Oscilloscope. Everything seems to work pretty fine, Vcore is inbetween 1,4V and 1,9V in the levels 0 .. 3, which I guess is just right. MY CPU now really kind of trips when I set the MCLK to 25 MHz and afterwards try to adapt the Vcore level to an higher value so it fits its demands.

One thing that is bothering me, is the LPM current. Now with adaption of SetVCoreVoltage i get aroun d 5,4 µA LPM3 current, before my usage of SetVCore i got down to 2,3 µA but the code now seems more reasonable than before, so i am a little bit confused. But as long as my MSP430 is running for sure and guranteed I will take that extra current and trade it for reliability.

I will keep this up when I do additional measurment.

Thanks for reading.

Seb

seb said:

MY CPU now really kind of trips when I set the MCLK to 25 MHz and afterwards try to adapt the Vcore level to an higher value so it fits its demands.

Well, that's like kicking someone out of a plane and then trying to give him a parachute for a safe landing.

You must first raise PMMCOREV and when the coltage has successfully risen (takes some time) then you may raise MCLK.

seb said:

with adaption of SetVCoreVoltage i get aroun d 5,4 µA LPM3 current, before my usage of SetVCore i got down to 2,3 µA

Well, that's no surprise. Havign a higher output voltage out of the switching regulator means having a higher current draw from the input voltage.
YOu may slow down MCLK and then lower PMMCOREV before entering LPM, adn on wakeup rise PMMCOREV, wait and then raise MCLK. THis brings your LPM current down, btu at the cost of additional waiting time on wakeup. Well, maybe you don't need the high MCLK during ISR, only if main is awakened, so the delay only appears when you wake main bu tnot during interrupts while in LPM.