STM32F405 STOP mode UART issue

[Deep Gadhia]

Posted on January 09, 2018 at 15:07

Hello,

I am working on application which require low power and serial USART communication. Using HAL CubeMx library We are able to STOP mcu clock and wake up on external interrupt correctly. Now for wake up on UART data, we have configured UART Rx pin to external interrupt pin. Application logic as follows

1) Enable external interrupt pin( which is physically shot with UART Rx pin)

2) Pause UART data (Abort Tx and Rx interrupt of UART)

3) STOP mcu clock

4) configure Clock

5) disable external Interrupt

6) Resume UART interrupt and put mcu to Rx mode using HAL_UART_Receive_IT api.

7) put timer for delay of 1 sec for keep Wake up mcu so that UART data receive.

Through testing we came to know that noise error comes after wake up. so we put error handle conditions for receive data.

Now problem is that we are getting garbage data some times not every time and first byte loss every time. Garbage data comes through space char most of time for example 'Good Morning' comes '****Morning'. Byte loss is acceptable but garbage data comes some time that is giving problem.

Please help us to solve issue.

Thanks in advance.

#wake-up-from-stop-mode #usart-rx #stm32-f4 #low-power-stop-mode

[Andrew Neil]

Posted on January 09, 2018 at 19:23

Is the 'garbage' being received by the STM32?

Or is it seen by whatever is connected to the STM32?

Or both?

[Deep Gadhia]

Posted on January 10, 2018 at 08:27

Hello,

For testing We have done whatever char received that will echo back on Tx pin. So that on serial terminal we can see sent chars. In debug mode STOP mode not working even if we use 'HAL_DBGMCU_EnableDBGStopMode()' api. 'garbage' seen on serial terminal.

Thank you.

[Andrew Neil]

Posted on January 10, 2018 at 12:42

So you don't actually know whether the corruption is happening in the microcontroller receiving, or in the microcontroller transmitting - or both.

It could also be an 'artefact' of the (unspecified) terminal you're using.

eg, see: 

http://www.avrfreaks.net/forum/teraterm-problem-again?skey=teraterm