I am working on a board that uses an STM32F411 connected to a bluetooth module over USART. One of the goals is to enable Low-power consumption in STOP mode.

A brief summary of the platform:

  1. The Bluetooth module can wake up the STM32 using an EXTI interrupt when it has data to send.
  2. I have an interrupt handler to handle the interrupt in (1).
  3. The STM32 enters stop mode in the RTOS's idle thread once it detects that no threads are interested in keeping the MCU awake.

I am able to get the processor into Low Power STOP mode. However, when the Bluetooth module wakes up the MCU to commence data transfer, the MCU picks up junk data over the USART.

I have tried using the alternate function of the USART RTS gpio - I set it high so that the bluetooth module cannot send any data over the USART until I am ready. In my ISR, on receiving the Bluetooth interrupt, I signal a thread to re-initialize the USART at the same rate that it was receiving data at, prior to STOP mode.

I am not sure why the USART is behaving in this manner. As per the documentation, the configuration in STOP mode is required to be preserved across the low power mode.

I would appreciate some pointers for debugging this issue. Thank you in advance.

Please let me know if you need any more information.

EDIT: Found out the cause of the issue. When the processor wakes up, the uart has already transferred/lost some data; because of this, the handler for the data gets corrupted bytes. The solution that I finally used involved setting the RTS to HIGH prior to sleep; when the processor wakes and is ready to accept data, it pulls the RTS low and reconfigures the pin as a UART pin. This fixes the issue.

Thanks for your suggestions.

  • \$\begingroup\$ Can you try a different sleep mode that keeps the clock running to the USART? \$\endgroup\$ – jonk Jan 10 '17 at 8:32
  • \$\begingroup\$ I need the power numbers that the STOP mode provides. If I use the SLEEP mode, then I will get larger current values. \$\endgroup\$ – SSB Jan 10 '17 at 9:02
  • \$\begingroup\$ Does the UART data ever revert back to the expected data? Or is the entire packet garbled? If only a few bytes are incorrect, I would suspect synchronization errors. If all bytes are wrong, that is likely a UART configuration problem. Is the UART peripheral reporting any errors (framing, overrun, break, etc.)? \$\endgroup\$ – M D Jan 10 '17 at 9:09
  • \$\begingroup\$ The UART never reverts to the expected data. All the bytes seem to be wrong. I will check for the UART errors and update shortly. \$\endgroup\$ – SSB Jan 10 '17 at 12:39
  • \$\begingroup\$ @SSB I wasn't asking about it as a long term solution. I was asking about it as a test to see if stopping the clock to the USART is the problem, or not. \$\endgroup\$ – jonk Jan 10 '17 at 17:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.