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.

IAR device is stuck and cannot attach debugger

Other Parts Discussed in Thread: MSP430F5327

Hi,

Sometimes I see some devices that seem stuck (usually there is a UART interface to query the device status). 

When trying to attach the debugger in IAR this message appears: "Warning CPU is off (Low Power Mode) and interrupts are disabled. Cannot execute step/go)."

I can't seem to find what this means exactly. The device goes into low power mode when using SPI/UART whilst waiting for flags from interrupts to be set usually. 

Can anyone suggest what things I can do to get more information? 

Any help is much appreciated. The device used is a MSP430F5327

  • Garry,

    You cannot step through your code when the device is in LPM, because during this time the CPU is disabled. The alternative to this is to set breakpoints either in ISRs or within a portion of the code where the CPU will be active. This ensures that the device will be in active mode when it stops and you will be able to read registers, look at local variables, etc at that point in time.

    Another tip for you is that when you are using the debugger and LPMs, you should place a __no_operation(); command right after the __bis_SR_register(xx); command. This allows the debugger to point to the __no_operation(); when it is in LPM.

  • Hi,


    Thanks for your reply. The device really shouldn't be in low power mode (unless its waiting for a SPI/UART TX/RX to finish). So maybe thats a clue!

    I will try your suggestion about the _no_operation - thanks!

  • Tyler Witt said:
    when you are using the debugger and LPMs, you should place a __no_operation(); command right after the __bis_SR_register(xx); command. This allows the debugger to point to the __no_operation(); when it is in LPM.

    AFAIK, the purpose of this NOP is different: it allows you to put a breakpoint on the C command after the LPM entry, without being fooled by the processors pre-fetching (a breakpoint on this NOP would be triggered before LPM is entered, as the CPU fetches the NOP the very same moment LPM goes active. And breakpoints trigger on instruction fetch)