STOP1 UART Wakeup 115200

[MVeen.1]

Post edited by ST moderator to be inline with the community rules for the code sharing. In next time please use </> button to paste your code and a linker script content. Please read this post: How to insert source code.

I have a STM32L433RCT3 and I'm exploring using the USART wakeup feature from STOP1 on RXNE. To improve the wakeup time and not miss any data, I clock the USART directly from the HSI and I configured the wakeup clock to be the HSI. I'm wondering if someone could confirm this is a safe thing to do at 115200 baudrate? I'd rather not use the USART's UCESM: USART Clock Enable in Stop mode bit to keep the clock running in STOP1 mode (significantly more sleep current).

From what I understand, the HSI takes a maximum of 6.2us to start up & stabilize? (Section 6.3.8 of Datasheet). Do you add the startup time (1.2us) and the stabilize time (5us) or do I just take the stabilize time? 
At 115200 baudrate, there is a bit coming every 8.68us. Theoretically, do I have the time to wakeup, start/stabilize the HSI, process the USART byte (Interrupt into ring buffer), and not mess-up receiving the next byte? I enable irq right after STOP1 mode to ensure the RXNE interrupt is serviced ASAP.

 

 HAL_SuspendTick();
 HAL_PWREx_EnterSTOP1Mode(PWR_STOPENTRY_WFI);
 __enable_irq();
 HAL_ResumeTick();

 SystemClock_Config_fromSTOP();

I'm seeing it work on the bench, but I'm not sure how close I'm getting to the edge of what is safe operation? 
Any help is appreciated, thanks!

[Gyessine]

hello @MVeen.1 
I recommend waiting the full 6.2 µs as the datasheet states to ensure that the clock has sufficient time to start and stabilize.
For your second part, I did not understand if you are asking whether it is doable or if you have already completed it and have the project working.
Just in case, I tried replicating your case on my end, and it worked successfully using the 115200 baud rate.
I am going to attach the code snippet that I used along with a screenshot of the results hoping it will help you

/* Initialize all configured peripherals */
 MX_GPIO_Init();
 MX_USART2_UART_Init();
 /* USER CODE BEGIN 2 */
 HAL_Delay(5000);
 HAL_UART_Transmit(&huart2, (uint8_t *)"Hello before entering stop1 mode\n", strlen("Hello before entering stop1 mode\n"), HAL_MAX_DELAY);
 HAL_SuspendTick();
 HAL_PWREx_EnterSTOP1Mode(PWR_STOPENTRY_WFI);
 SystemClock_Config();
 __enable_irq();
 HAL_ResumeTick();

 HAL_UART_Transmit(&huart2, (uint8_t *)"Hello after getting out of stop1 mode", strlen("Hello after getting out of stop1 mode"), HAL_MAX_DELAY);
 /* USER CODE END 2 */

 

Gyessine

 

[MVeen.1]

Hi Gyessine,

Sorry for the confusion. I was just saying that I was able to get the code to work, but I'm more concerned on how dependable this behavior is. The example you're showing is a bit different because you're transmitting and the HAL command waits for the USART TDR register to be empty before loading it again. I'm receiving and the incoming data won't wait for my USART RDR register to be empty first.

 

Assuming the worst case of 6.2us for the HSI to stabilize (assuming USART is now stable too?), do I only have a ~2.5us buffer to deal with the data in the USART RDR register before the start bit of the next incoming byte at 115200? I'm not sure how to quantify if that is enough time. Maybe my MCU is not near the 6.2us worst case and that is why it works?

For context, here is my USART interrupt callback (only reads) and the function that puts the byte into a ring buffer:

void UART_IT_IRQHandler(UART_HandleTypeDef *huart){
 uint32_t isrflags = READ_REG(huart->Instance->ISR);
 uint32_t cr1its = READ_REG(huart->Instance->CR1);
 uint32_t errorflags = 0x00U;

 errorflags = (isrflags & (uint32_t)(USART_ISR_PE | USART_ISR_FE | USART_ISR_ORE | USART_ISR_NE | USART_ISR_RTOF));
 if (errorflags == RESET){ 
 if (((isrflags & USART_ISR_RXNE) != RESET) && ((cr1its & USART_CR1_RXNEIE) != RESET)){
 ring_buffer_write(&rx_ringbuffer_PC,(uint8_t)(huart->Instance->RDR & (uint8_t)0x00FF)); 
 
 if(!UiTask.status && !(cr1its & USART_CR1_IDLEIE)){
 __HAL_UART_CLEAR_FLAG(&huart3, UART_CLEAR_WUF);
 UiTask.status=RUN;
 }

 return;
 }
 }else{
 __HAL_UART_CLEAR_FLAG(huart, UART_CLEAR_PEF | UART_CLEAR_FEF | UART_CLEAR_OREF | UART_CLEAR_NEF | UART_CLEAR_RTOF);
 }
}

bool ring_buffer_write(ring_buffer_t* rb, uint8_t byte){
 /*Store local copies of indexes*/
 uint32_t local_write_index = rb->write_index;
 uint32_t local_read_index = rb->read_index;

 /*Check buffer isn't going to fill up*/
 uint32_t next_write_index = (local_write_index+1)&rb->mask;
 if(local_read_index==next_write_index){
 return false;
 }

 rb->buffer[local_write_index] = byte;
 rb->write_index = next_write_index;
 return true; 
}

[Gyessine]

hello @MVeen.1 
there is a point that I want to clarify,
I see that you are focusing only on the HSI wake up time.

Based on the datasheet, the wake-up time from Stop 1 mode (which is the process from the start of the wake-up process to the execution of the first instruction) is set to a maximum value of 8.1 µs when using flash memory. This time includes the 6.2 µs required for the HSI to start and stabilize, as well as the time needed for all other peripherals, including UART.

So, the question should be whether the 8.68 µs window is sufficient for the entire product to wake up from the start time and to reconfigure the clock again, not just the HSI. To address this, the 8.4 µs maximum value is guaranteed by characterization results based on the datasheet. Therefore, and if reconfiguring the system clock again does not take more than the time left. it should be sufficient as an expected behavior.

You can run tests and provide feedback in case you encounter any issues.
here is the low power mode wake up timings for reference 

I also want to point out to you the section "Determining the maximum USART baud rate allowing to wake up correctly from Stop mode when the USART clock source is the HSI clock" in the reference manual
you need to do your calculations and verify if your UART can handle 115200 baud rate in your conditions

Hope that helps
Gyessine

[MVeen.1]

"Determining the maximum USART baud rate allowing to wake up correctly from Stop mode when the USART clock source is the HSI clock" is exactly what I was looking for! In STOP1, my calculations show that 115200 is too fast to be guaranteed a proper wakeup. The fact that it was working on my bench must have been due to ideal wakeup conditions/timing.