Wakeup from Deep Sleep by BLESS will affect the Rx buffer size of UART.

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hi everyone,

   

I tested my BLE project in the CY8CKIT-042-BLE, I configured an UART and checked "Enable wakeup from Deep Sleep Mode"; Also I put the UART_Sleep() and UART_Wakeup() before/after the CySysPmDeepSleep()  in low power implementation.

   

When the procedure exits from Deep Sleep by BLESS (I was sure that did not cause by Rx GPIO because the Rx GPIO was always HIGH on the oscilloscope), the UART_SpiUartGetRxBufferSize() will return 0x01, and UART_UartGetByte() will get the value 0xFF.

   

For simplification, I created a simple project (BLE_Battery_Level) from the Code Example and put the necessary code to this example for testing, run it in the CY8CKIT-042-BLE and it got the same problem.

   

(I have attached the archived file of this example.)

   

I stuck in this problem a bit of time, has anyone can help me?

   

Thanks!!

   

Aaron Deng

0 Likes
11 Replies
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

I think before going to deep sleep you need to send the peripherals to sleep to, and restore their state afterwards.

0 Likes
Anonymous
Not applicable

Hi hli,

   

I had put the UART_Sleep() and UART_Wakeup() before/after entering/exiting Deep Sleep.

0 Likes
Anonymous
Not applicable

Aaron,

   

 

   

Can you raise a technical case at http://www.cypress.com/support ?

0 Likes
Anonymous
Not applicable

Hi roit,

   

I have created a technical case, the case# is 3027374751.

   

Link : https://secure.cypress.com/myaccount/?id=25&myCase=489394-3027374751

   

Aaron Deng

0 Likes
Anonymous
Not applicable

Hi Aaron,

   

Do you fix the problem? There is the same issue with my code.

   

I implemented the deep-sleep mode, the uart_rx can wake system up, but the rx buffer is filled with 0xff.

0 Likes
Anonymous
Not applicable

Hi Derrick,

   

The following message was responded from technical support for your reference.

   

=================================================================================================

   
    In UART_Sleep function, it operates UART_RX_CTRL_SKIP_START. It's the root cause.    
    
When Skip Start register is set after wakeup, the UART tries to receive data bytes and synchronize 1st data bit by reading Rx FIFO. If UART is waked up by Rx input, everything goes correctly, but if wakeup source is from non-Rx interrupt, error will occur during the process.    
    
     The problem is UART doesn't know who triggers wakeup interrupt.     
    
   

=================================================================================================

   

Another issue, the UART will synchronize the 1st data bit after every time system be woke up, if the non-Rx interrupt and Rx interrupt take place at the same time or too closed, the Data Collision (the 0xFF dummy data and UART input data) will happen .

   

This support case is pending and waiting for replying from technical support team, they need more time to find a good solution on this issue.

   

In my application, I don't use the UART_Sleep() & UART_Wakeup() before and after Deep Sleep, but I used one GPIO as RS232's RTS, when the device needs to send data to PROC-BLE MCU, to pull low the RTS signal to wakeup and notify that it will send data to and keep it out from deep sleep. this method can avoid the generation of 0xFF dummy data and data collision, for your reference.

   

Regards,

   

Aaron Deng

0 Likes
Anonymous
Not applicable

Hi Aaron,

   

Thank you very much. you mean to wake the system up by a GPIO interrupt actually?

0 Likes
Anonymous
Not applicable

Yes, this is the best solution that I can figure out until now, if you have another solution, you can share with and post on community.

0 Likes
Anonymous
Not applicable

Hi Aaron,

   

Below is another solution, it does not need to consider the flow control.

   

The RX pin connects with GPIO pin together, the UART start bit(Falling edge) will trigger the GPIO interrupt and wake system up, then system to synchronize the data. 

   

Any comments?

0 Likes
Anonymous
Not applicable

Hi Derrick,

   

Thanks for your sharing, it is a good way to wake system up from deep sleep, but it may cause the system busy to handle the GPIO interrupt for every falling edge of low bit, and the power consumption is higher because of the system leaves from 'Sleep' mode frequently while UART data input, this was my concern, so I chosen the waking up by independent GPIO.

0 Likes
Anonymous
Not applicable

Hi Aaron,

   

Yes, the frequent GPIO interrupt will consume more power, however, we can disable the interrupt when the system is waked up by start bit, then execute the code and synchronize the data, in the end ,enable the interrupt again. In fact, the UART_RX interrupt wake-up is a GPIO falling edge interrupt wake-up. also, as the wake-up time(25us) must be less than one bit duration, the baud rate should be less than 40000(eg.38400) , but, if use a separate pin as wake-up source, we can set a higher baud rate, this is an advantage of separate pin.

0 Likes