USART Issues after wake up from stop mode

[r23]

Posted on December 03, 2013 at 19:56

Hello,

I've succesfully started programming a STM32F0Discoveryboard:

• MCU is running on HSI (8MHz) at runmode.
• MCU is going into/outof stopmode every 5 seconds using the RTC running on LSE (32.768kHz)
• USART1 is connected to pc (9600 baud)

After initialization (GPIO, USART, RTC) the USART works just fine using the USART_SendData() and USART_ReceiveDate() functions. But the when the MCU is put into stop mode and subsequently wakes up, the USART1 is not longer functioning properly. Weird characters show up in my terminal, so i assume this is a timing error.

I can post the code, but maybe this issue sounds familiar to anyone? Hope you can help!

Thanks,

Ronald

#stm32-usart-stop

[Tesla DeLorean]

Posted on December 03, 2013 at 21:01

Verify the clock source (+ configurations) and baud rate register.

RCC_GetClocksFreq()?

Check the bit timing with a scope.

[r23]

Posted on December 03, 2013 at 22:49

I think you pointed me in the right direction! RCC_GetClocksFreq() must be called for an update. However i'm not sure which arguments to use.

[Tesla DeLorean]

Posted on December 03, 2013 at 23:03

No, I'm saying use it to determine the clock basis when it comes back.

RCC_ClocksTypeDef RCC_ClockFreq; /* This function fills the RCC_ClockFreq structure with the current frequencies of different on chip clocks (for debug purpose) **************/ RCC_GetClocksFreq(&RCC_ClockFreq);

/**
* @brief Returns the frequencies of the System, AHB and APB busses clocks.
* @note The frequency returned by this function is not the real frequency
* in the chip. It is calculated based on the predefined constant and
* the source selected by RCC_SYSCLKConfig():
*
* @note If SYSCLK source is HSI, function returns constant HSI_VALUE(*)
*
* @note If SYSCLK source is HSE, function returns constant HSE_VALUE(**)
*
* @note If SYSCLK source is PLL, function returns constant HSE_VALUE(**)
* or HSI_VALUE(*) multiplied by the PLL factors.
*
* (*) HSI_VALUE is a constant defined in stm32f0xx.h file (default value
* 8 MHz) but the real value may vary depending on the variations
* in voltage and temperature, refer to RCC_AdjustHSICalibrationValue().
*
* (**) HSE_VALUE is a constant defined in stm32f0xx.h file (default value
* 8 MHz), user has to ensure that HSE_VALUE is same as the real
* frequency of the crystal used. Otherwise, this function may
* return wrong result.
*
* - The result of this function could be not correct when using fractional
* value for HSE crystal.
*
* @param RCC_Clocks: pointer to a RCC_ClocksTypeDef structure which will hold
* the clocks frequencies.
*
* @note This function can be used by the user application to compute the
* baudrate for the communication peripherals or configure other parameters.
* @note Each time SYSCLK, HCLK and/or PCLK clock changes, this function
* must be called to update the structure's field. Otherwise, any
* configuration based on this function will be incorrect.
*
* @retval None
*/
void RCC_GetClocksFreq(RCC_ClocksTypeDef* RCC_Clocks)
......
typedef struct
{
uint32_t SYSCLK_Frequency;
uint32_t HCLK_Frequency;
uint32_t PCLK_Frequency;
uint32_t ADCCLK_Frequency;
uint32_t CECCLK_Frequency;
uint32_t I2C1CLK_Frequency;
uint32_t USART1CLK_Frequency;
}RCC_ClocksTypeDef;

[r23]

Posted on December 04, 2013 at 11:49

Hi Clive,

I checked the clock frequencies before and after stop mode. They all are 8MHz (SysCLK, HCLK, PCLK and USART1CLK). The baud register USART1->BRR is 0x00000341 before and after stop mode.

What is even more strange. USART is working ok in debug mode. I send the character 'A' (each main loop cycle) to my pc and receive character 'A' each cycle in debug mode. However when i run the code I receive:

• a 0xFF the first cycle
• a 0xD0 and a 0xFF every subsequent cycle

So, i'm rather confused and it looks like it will be difficult to find the problem in debug mode.

[r23]

Posted on December 04, 2013 at 12:27

Solved!

I think the mcu went into stop mode before the full byte was send. I added the second line:

[code]

USART_SendData(USART1, 'A');

while(USART_GetFlagStatus(USART1, USART_FLAG_TC)== RESET);

while(USART_GetFlagStatus(USART1, USART_FLAG_TXE) == RESET);

[/code]

Thanks!

[Tesla DeLorean]

Posted on December 04, 2013 at 17:20

Yes, you'd probably want to front test for TXE, and back test for TC to ensure the last bit hit the wire. Same kind of issues with changing baud rates on the fly.