Waking up on UART data

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Muis on Tue Jan 29 11:03:13 MST 2013
I have a LPC11U35 and I would like to wake from deep-sleep on incoming UART data. When the baudrate is low enough I could just connect the RX to a GPIO pin and wakeup from that, but my baudrate is 115200, and waking up from deep-sleep takes 65 microseconds, so I'm afraid I will miss the first characters.

I also thought about enabling flow-control, but the peripheral I'm connected to only asserts the line when its buffer is full, but not when it tries to send something. I dont know if this is a normal for a CTS/RTS scheme, but I cannot do anything about it.

Are there any other options left?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Tsuneo on Tue Feb 05 03:13:48 MST 2013
On the LPC11U3x data sheet,
http://www.nxp.com/documents/data_sheet/LPC11U3X.pdf

9. Static characteristics
Active mode at 12MHz: 2 mA typ.
Sleep mode at 12MHz: 1 mA typ.
Deep sleep mode : 300 uA typ.
Power down mode : 2 uA typ.
Deep power-down : 220 nA typ.

Also on the data sheet, you'll see "Table 8. Power consumption for individual analog and digital blocks"

Quote:

I often wondered how it's possible this difference is so large,

I believe the difference comes if FLASH clock is kept or not, but not tested yet on LPC11Uxx family. RAM code to drop FLASH clock will probe it.

Tsuneo

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Muis on Sun Feb 03 12:40:52 MST 2013

Quote: Rob65
How did you measure this?
Note that the LPCXpresso board also contains the LPC-Link and this will add something to the power taken by the board.
You must sever the link between the target processor and the LPC-Link part when measuring power.

Power consumption will also depend on other things you have connected to the processor. The logic level of the pins remains static. If you have input pins with a pull up active (and a low level on the input) this will add to the powerconsumption. Also high level output pins with some load connected (e.g. an LED) add to the power consumption.

Thanks for the tips! I will try them out tomorrow. However I assume NXP measured it themself under the most optimal circumstances, and their application-note specifies:

Sleep mode (IRC (12 MHz), all peripherals off): 2 mA
Deep-sleep Mode (Watchdog Osc off and BOD off): 2 μA

So if I did something wrong during measurements, your former employee did too ;)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Rob65 on Sun Feb 03 06:10:36 MST 2013

Quote: muis

I'm really puzzled by this comment, because with all peripherals off I'm still using over 2 mA (at 12Mhz) in normal sleep, while in deep-sleep it should be around 20 μA. I often wondered how it's possible this difference is so large,

How did you measure this?

Note that the LPCXpresso board also contains the LPC-Link and this will add something to the power taken by the board.
You must sever the link between the target processor and the LPC-Link part when measuring power.

Power consumption will also depend on other things you have connected to the processor. The logic level of the pins remains static. If you have input pins with a pull up active (and a low level on the input) this will add to the powerconsumption. Also high level output pins with some load connected (e.g. an LED) add to the power consumption.

Rob

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Muis on Sat Feb 02 16:27:44 MST 2013

Quote: Tsuneo

- IRC (12Mhz) is tuned in +/- 1% in factory. It's enough for RS232 tolerance.
- The timing, in which the system clock switches from IRC to PLL, may be critical, so that it doesn't affect to USART reception. Switch the clock while the RX line is silent, after the first block of data.

I'm already on the IRC (because I assumed its more power efficient than using the external crystal), so I dont need to switch clocks after wake up.

Quote: Tsuneo

- Power consumption in sleep mode may reduce as much as those on deep sleep, when the peripherals, other than USART, aren't fed clock.

I'm really puzzled by this comment, because with all peripherals off I'm still using over 2 mA (at 12Mhz) in normal sleep, while in deep-sleep it should be around 20 μA. I often wondered how it's possible this difference is so large, but its consistent with app-note AN11027 where NXP specifies 6 mA in normal sleep (at 48Mhz) (with all peripherals disabled), and 6 μA in deep-sleep. The reason for this large difference is not clear to me.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Tsuneo on Sat Feb 02 10:29:19 MST 2013
Just an idea.
You may keep the USART runngin over the internal RC OSC (IRC), while the MCU drops in "sleep" mode, instead of deep-sleep.
- As the USART has 16 bytes FIFO, it can hold as many number of incomming data bytes, before the MCU core wakes up.
- IRC (12Mhz) is tuned in +/- 1% in factory. It's enough for RS232 tolerance.
- The timing, in which the system clock switches from IRC to PLL, may be critical, so that it doesn't affect to USART reception. Switch the clock while the RX line is silent, after the first block of data.
- Power consumption in sleep mode may reduce as much as those on deep sleep, when the peripherals, other than USART, aren't fed clock.

Tsuneo

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Muis on Sat Feb 02 05:03:12 MST 2013
The problem is that I don't control the device that is sending me the data. If I could, then your suggestion of first sending some 'useless' data and then the 'real' data would work, but unfortunately I cannot change it's packet format.

The only solution I can see would be connecting the RX line to an GPIO interrupt and wake up from that, and have the data to the real RX pin fed through some hardware that delays it, so I wake up in time to capture.

I really hope there would be a nicer solution, but it seems we're out of luck :(

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CroesJeroen on Fri Feb 01 15:27:38 MST 2013
I've also encountered this problem. The start up times also depends on the main clock frequency. Try to capture the RX buffer if youre sleeping and sending 2 data chunks after each other.

You can use the change on line status (don't remember the name RLS?) of the RX input so it wakes up and you don't have to wait until the full by is in the RX buffer. You have to read the data from the buffer before the full second data chunk is received and will evict the first chunk.

Kind regards