Hello again!

I'm trying to set an LPC1751 to enter Powerdown mode and wake up after
either RTC alarm irq or GPIO irqs. As far as I read, any enabled irq wakes
the processor from sleep modes (opposed to other LPC uC's that have a
wake-up enable register.bit for every peripheral).

I have the following setup for GPIO:



and for RTC:



Then to enter Sleep mode I shut down PLL0 as stated in the errata and after
that emit a __WFI( ); instruction

The problem is the uC is woken up immediately. I've checked the following
irq registers:

Interrupt Set-Enable Register 0 register (ISER0 - 0xE000 E100)
Interrupt Set-Pending Register 0 register (ISPR0 - 0xE000 E200)
Interrupt Active Bit Register 0 (IABR0 - 0xE000 E300)

and reading them right after __WFI( ) I get:

Enabled IRQs: 0x20624080
Pending IRQs: 0x00010000
Assertd IRQs: 0x00000000

For the enabled, if read left to right nibble wise and skipping zeros:
2 = RIT
6 = ADC & EINT3
2 = RTC
4 = SSP0
8 = UART2

For the pending, the only 1 shown corresponds to PLL0, which confuses me
double. First, since it is not enabled according to the enabled register,
second, it's disconnected!

The questions would be why PLL0 keeps interrupting, how to avoid that, how
to set the RTC and GPIO interrupts to wake up the processor when they should
and how to set up other power saving modes as Deep Sleep and Power Down?

For the last I tried



But it hang up the uC =)

Does anyone have any advise on this? Being as it is that this is a known
faulty area I would have expected an example in the NXP code bundle

Thank you all, best regards!

PS: Mail should have [code] [\code] tags by now! Perhaps a good proyect for
google labs or similar.
--
Nicol Christie
n...@gmail.com Start a New Thread

Hi:

Power down mode is a little bit tricky sometimes.

First of all, on the LPC17xx processors, debuggers cannot be used when in power down mode because they cannot connect to the processor once it enters power down mode. Not even after the processor comes out of power down mode. You need to reset the processor to be able to debug again.This might explain your processor hang ups. Therefore, the first recommendation is to verify the wake up conditions without actually entering power down more.

The way I have done it in the past is to use a while loop entering power down mode, and using a volatile variable, updated in the Interrupt Service Routine to get out of the loop:



I can test all the wake up logic by commenting out the _WFI() instruction.

Another tip is to use the Internal RC clock as the clock source when entering power down mode. This means, to turn off the PLL0 and switch clocks to IRC before entering power down mode. The rationale for this is that the IRC wakes up much faster (hundreds of microseconds) than the external oscillator.

Regards,

Alex. Start a New Thread

Alex, thank you for the reply!

What you say is true, however, adding information to my first post, I'm not
using any debugger, so that should not be the reason for the hang. The RIT
interrupt will hang every time I try to call some a function from within it.
Would the use of other peripherals cause this hang? That is, say I try to
send data through UART (which would cause THRE interruptions) from a RIT
interruption, this would mean a nested interruption should occur. Doesn't
the NVIC take care of that? How can I check if nesting is enabled?

Secondly, I agree your method for entering power saving modes will
effectively keep the uC in that state until any of the "authorized
interruptions" are triggered, but this does not solve the fact that it is in
fact waking up all the time. For a low power application that intents to
save energy, it's not the optimal solution.

Regards, Start a New Thread

Hi Nico,

The nested interrupt should be enabled by user, manually, by issuing 'cpsie i',
at the beginning of interrupt handler (after saving / restoring the necessary
register context of course).

See http://ics.nxp.com/support/documents/microcontrollers/zip/an10915.zip for
using LPC17xx Power Modes.

Regards,
-daniel Start a New Thread

Hi Daniel, thank you for the reply! I had found that app. note but not with
the code example attached, so that helped me out!

The connection of PLL1 to disable the USB clock and lower consumption seems
to have fixed the continuous PLL0 irq I had before, even if I disconnected
it.

Thanks again, best regards! Start a New Thread