• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 79 subscribers
  • Views 1263 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Low power mode debugging behavior?

Nipun Gunawardena
Intellectual 585 points
Other Parts Discussed in Thread: MSP430FR5969

Hi All,

I am currently working on a program that seems to always hang on the line right after I put the MSP430FR5969 into low-power mode. This happens regardless of the low power mode I set it to (LPM0, LPM1, etc.). It doesn't actually run the line right after the low-power mode line, it just stops there. For example, the following code will hang, I will press "pause" in CCS, and it will say it's paused on the second line (where I set P4.6). However, P4.6 isn't actually set, because if it was the LED would be on.

__bis_SR_register(LPM0_bits);     // Enter LPM0
P4OUT |= BIT6;                    // Turn on LED connected to P4.6

I have tried setting a breakpoint on the hanging line, and it will stop there, but I can't go any further. Does this mean that the microcontroller is still in a low-power mode? What is the expected behavior of the debugger when the microcontroller is in low-power mode?

Thanks in advance for any help!

- NG 

  • 0
    Guru 33653 points
    Well, I guess that something must wake it up from sleep. No wake up, no possibility for executing following line.
  • 0 in reply to zrno soli
    Intellectual 585 points
    Hi zrno,

    Thank you for your quick response. You're right, I do have something (an external pin-driven interrupt) that should wake up the uC, but it's not working right now. The problem is that I can't determine whether it leaves the low-power mode and then hangs, or it only appears to leave low-power mode but is actually still in it. I was going to post a separate thread showing more details with the code, but I was wondering whether the answer to this thread would help me debug a little more.

    Thanks again,
    NG
  • 0 in reply to Nipun Gunawardena
    Guru 33653 points
    Again, I guess that problem is interrupt. You can replace entering to low power mode, with loop that will blink some LED. And when you are sure that everything is OK with interrupt, replace loop with low power mode. At the end of interrupt you must leave low power mode (bic LPM bits) if you want to your main program continue with execution.
  • 0
    Guru 227245 points
    A breakpoint is triggered when the CPU fetches the instruction the breakpoint is set on.
    Entering low power mode, simply stops the CPU clock.
    However, the very moment the clock stops, the CPU has already fetched the next instruction, which triggers the breakpoint even though no interrupt was triggered yet and the CPU is sleeping.

    For this reason, many demo codes contain a NOP instruction right after entering LPM with the comment 'for debugger'. This comment is misleading. the NOP isn't there to put a breakpoint on it, but to NOT put a breakpoint on it (but put a breakpoint on the next real instruction after exiting LPM).
    This is a typical pit in which many new users have fallen (mainly because they didn't fully read and understand the CPU core chapter in the users guide)
    LPMs are no high-level OS functions but very low-level hardware operations that closely cling to the CPUs hardware architecture for maximum effect.

**Attention** This is a public forum