We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
GDay to all
I'd like to ask for tips and ideas on how to build the following - or reports of what did not work ;))
A battery-powered device intended for long term battery life. We need to wake up everynow and then to check states and measure some values. So the default state in 99.9% will be "sleeping"
1) what is the suggested way to get the RL-ARM to sleep and to wake up again. Or shall we "boot" just as if from reset (only leaving some valuable RAM unitialized
2) are there any samples out using USB and RL-ARM with tasks in order to show the integration of the Keil-USB into RL-ARM? All the USB samples I found were only bare without "OS"
3) as said above, the device will be usually sleeping. upon connection of USB, we need to wake up in order to serve the USB stack.
How would you put all that together ?
I'd tend to behave like after reset, either upon USB connection of RTC-Wakeup having a boot routine that looks for USB connection and starts the USB part only if connected.
any ideas highly appreciated ..... UB
1) Covered by putting the CPU to sleep with power to RAM. 2) Yes. See here:
C:\Keil\ARM\Boards\Keil\MCB2400\RL
3) You may be able to wake the device based on USB interrupts but I'm not sure. check your user manual.
Hello Tamir, once again and thanx for taking the time to answer...
3) Yes, the USB Activity interrupt / and a transition on VBUS should do the raw wakeup. I am aware of this. The question is how to properly integrate that all with RL-ARM
btw - I forgot: it is a LPC1768
NXP provides an app note on power modes covering this AN 10915 - but again without OS.
thanx for pointing to the MCB2400 sample. but this looks really so simple. I wonder if that can really be all...
__task void start (void) { USB_Init(); USB_Connect(__TRUE); os_tsk_delete_self(); }
I tend to believe that at first sight simply looking things turn out to be a nightmare in the end ;))) eg error handling / dis- or reconnect etc ...
My devices don't need to go to sleep (the machine at the other end is on the megawatt scale...) so I don't know in detail. I can say this: assuming RAM remains stable, you could keep it as simple as you want. I don't think it would be much different than, say, a BBR.
Hi Ulrich and Tamir,
> 3) Yes, the USB Activity interrupt / and a transition on VBUS should do the raw wakeup.
For ultra low-power setting while unpluged from USB port, you'll power down the USB module by PCUSB (PCONP) bit. Under this setting, USB activity interrupt is not available any more *1)
Plug-in detection is done by, 1) Connect a spare port of P0 or P2 to the VBUS (5V) pin of the USB connector, too, to enable port interrupt - wakeup function. OR 2) Periodically poll VBUS (P1.30) pin, which is set to GPIO mode by PINSEL3.
After the first detection of VBUS voltage, the firmware polls VBUS pin for a couple of time in 10-20 ms interval for debounce. When the USB power supply is confirmed, the firmware initialize the USB module and PLL, by USB_Init(). In this routine, USB module is powered, VBUS pin is set to monitor, PLL runs and USB interrupt is enabled. And then, USB_Connect(__TRUE) enables D+ pull-up resistor, which is detected by the host as USB connection. Host starts enumeration.
Unplug from USB port is detected by USB interrupt. Disconnection is reported in DEV_STAT bit (USBDevIntSt). "Get Device Status" protocol engine command confirms disconnection in CON_CH bit. Reverse the process of USB_Init() - disable USB interrupt, drop PLL and module power. Set up the port for plug-in detection, and then, enter to deep power-down mode.
*1) UM10360: LPC17xx User manual (user.manual.lpc17xx.pdf, rev 01) Chapter 4: LPC17xx Clocking and power control 8.8 Wake-up from Reduced Power Modes (p63) The CAN Activity Interrupt is generated by activity on the CAN bus pins, and the USB Activity Interrupt is generated by activity on the USB bus pins. These interrupts are only useful to wake up the CPU when it is on Deep Sleep or Power-down mode, when the peripheral functions are powered up, but not active.
Tsuneo
Tsuneo, many thanx for that.
btw - just curious: do you dream in in and out reports?
Uli
> btw - just curious: > do you dream in in and out reports?
At least, my wife testifies that I'm telling in sleep in human language, not in machine language (01111010 01111010 01111010 ...)