SCG0 is always 1

kusanagi said:

... Some of my firmware set SCG0 bit of Status Register 1 at the beginning of debug session. Then it never changes. ...

Do you mean to ask why some of your firmware sets SCG0 but never clears SCG0?

Or, do you mean you expect SCG0 to change to 0 automatically, but it did not?

Or, did you use Debugger to change SCG0 to 0, but it would not?

kusanagi said:

This is not any low power mode

e.g. you can have the MCU active and still switch ACLK off. This is Active Mode (CPUOFF bit is not set), yet sets one of the LPM bits.

I think, the whole construct of LPMs is a relic from the 1x series of MSPs where there were a rahte rlimited clock module and all the controls were in the status register and there were not that many ways to switch parts of the MSP off.

With the introduction of a second crystal and later with the orthogonal clock system - ACLK and SMCLK can be source from the same sources and used in all modules and SMCLK can be asynchroneous to MCLK, so the clocks should be ratehr called SCLK1 and SCLK2 - the meaning of the different LPMs has lost much of its significance. Especially since you can control whether or not a module that is still active can override teh LPM settigns and keep its clock active.

In your above example, the DCO is turned off if not required for CPU and SMCLK. If CPU and SMCLK are e.g. clocked by an external crystal, the DCO is no longer needed and can be shut off, even if the cpu is still active and no 'LPM' is entered.

SCG0 is not cleared automagically on leaving LPMs due to an interrupt.  This behaviour is in contrast to SCG1, OSCOFF and CPUOFF which are cleared automatically.  See slau208, chapter 1.4ff

SCG0=1 means, that the FLL is disabled - and luckily this bit isn't reset automatically, otherwise it would be impossible to solve some erratas (UCS7 and UCS10).

As a consequence, if you need the FLL and you (your firmware) has set SCG0, then you (your firmware) have to manually clear it too.

Hardy

Thank you for your comments. 

I want to know why SCG0 is set at the beginning of a debug session. 

With some firmware SR bits are (SCG1 -0, SCG0-0, OSCOFF-0, CPUOFF-0) after uploading of firmware. This is normal. 

But the firmware I am making now is different. After uploading SCG0 is already set. 

Regards,

Hmm, the firmware is not just uploaded - it already has started execution up to main().

What does SCG0 'say' if you do not execute after upload?

Hardy

kusanagi said:

After uploading SCG0 is already set

That's strange. Indeed, normally, SCG0 should be 0 after a reset.
It might be possible that during the upload process, the FLL is deactivated, and when the applicaiton is started diretly after upload, SCG0 is still set (no real hard reset)
It's also possible that the 'disable clocks' feature of the IDE (if there is one) affects the SCG0 bit.

What happens if you start a debug session without previous firmware upload (and the MSP was powered down in between)

The butler (or c start-up code) could have done it.

old_cow_yellow said:

The butler (or c start-up code) could have done it.

And there is no apparent reason why it happens with this particular firmware only. Since BSL check and startup code should be identical while using the same compiler.

Thank you for your comments again. 

I created a new project with the same source codes. But it didn't change anything.

I changed Project Property.

• Software Breakpoint Disable
• Erase Main Memory only
• Create Flash Image

I don't think this affects SCG0 bit. The setting is the same to other projects. 

In the debug session, even pressing Reset CPU button doesn't clear SCG0 bit. SCG0 sticks to 1.

Wonderland of MSP430?

Kusanagi

All you can do now is to strip down the firmware to zero, check whether it still happens, then start adding things again until it happens again. THen what you added must be what is causing this.

I am interested in an explanation too, but I have no more ideas without having the complete firmware (including the generated binary) in my hands. And I don`t have to time to look into this that deep, even if I had.

Mr. Jens-Michael Gross, 

I agree with you. After I check what routine causes this, I will be back here. 

Thank you.

Maybe it's not a single function, maybe it's a constant array or an initialized variable or such, that affects the automatically generated startup (variables init) code.

I found a while loop affected SCG0 bit.

while ( second < 5)
{
_bis_SR_register(LPM3_bits + GIE);       // Enter LPM3, enable interrupts
LED_Flash(1, 100); // LED1(Red) ON for 100ms 
} 

• Description
  Variable 'second' is 'extern unsigned int'. 
  Wake up by 1 second timer interrupt from LPM3. The interrupt routine increments 1 to 'second'.  

First I removed all codes of the main function other than watch-dog-timer disabling. 
And I left codes before and after the main function. 

Then SCG0 went 0 after uploading the firmware. It is normal. Then I found the while loop affected SCG0 bit. 
Then I left codes between {} of the while loop, that is,  removed a while construction there. Then SCG0 went 0.

while ( second < 5)
{
} 

This seems to affect SCG0 bit. But I don't understand it. 

That's really surprising.

Sure, the LPM3_bits settign includes setting SCG0, but it should only happen when the while loop is entered and not at program start.
I guess, your 1s tiem rinterrupt clears teh LPM3 bits?

I'd really like the generated assembly listing (if any).

It's always difficult to find such kidn of errors without seeing the whole code. Often the problem is in a part that is considered 'unimportant'. OTOH, I don't have the time to look through everyones code in full length, and often the code may not be disclosed in full too.

Today I added some features to the firmware. Then I saw SCG0 was 0 at the beginning of debug session. 
It is funny. I would not see this curious thing if I had made the firmware as today's.  

Really funny. It almost looks like a stack overflow issue, but this won't happen right at program start.