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.
Reply by Daniel Widyanto●October 17, 20102010-10-17
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).
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,
Reply by alexander_ribero●October 15, 20102010-10-15
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.
Reply by Nico Christie●October 14, 20102010-10-14
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:
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