STMG07 Uart Config after exit System Bootload

[TesterSAM]

Hi,

I have an issue with the UASRT communication being abnormal.

First case:

1. Access System Bootload Mode by Options bytes
2. Access the Main Application by the UART protocol ( UART2)
3. Send the first UART packet to the ST MCU via UART2 that contains the UART error code: 0x4 (Frame Error)
4. Send the same UART packet to the ST MCU via UART2 again without the UART error code

Second case:

1. Using IDE Debug Mode, break at main()
2. Send a UART packet to the ST MCU via UART2 without the UART error code

I tried to De-Init and Re-Init the UART2, which I expect to reset all the UART2 register values before I send the UART packet.

 

According to my test case, could I say that the UART error code 0x4 is due to System Bootload Mode?

How could I fix the issue?

Please let me know if more information is required.

[Saket_Om]

Hello @TesterSAM 

Please describe your issue with more details. What is the issue exactly? 

[TesterSAM]

I did not expect to get any error code in the UART register when I tried to send the UART Packet to the ST MCU via UART2 after exiting System Bootload Mode (using UART2 to exit the System Bootload mode and access the main application).

 

Although the second packet contains no error, I would like to know the root cause that led to the UART error code:0x4

 

In the ST MCU application, I expected to send a UART packet to execute the ST MCU function.

If the first packet is always ignored due to a Frame Error, the other MCU timing that sends the UART packet would be influenced.

[Guenael Cadier]

Hi @TesterSAM 
2 things tou could check/try:

1) If the Frame Error bit is set in the ISR of the UART instance you are using after your Init, you could try to clear it by calling 

 __HAL_UART_CLEAR_FLAG(huart2, UART_CLEAR_FEF);

before your reception on embedded side

2) you mention you perform a DeInit/Init procedure of UART before starting the reception. It is expected that the HAL_UART_DeInit() call, executes the HAL_UART_MspDeInit() function.
Please check that you have those 2 macros executed in HAL_UART_MspDeInit() for UART2 case.

 __HAL_RCC_USART2_FORCE_RESET();
 __HAL_RCC_USART2_RELEASE_RESET();

This should reset the flag in ISR.
Regards

[TDK]

Look at the signal on the line with a logic analyzer to figure out what's going on. Is TX pulled up with a pullup resistor? FE indicates the line is not stable, probably dipping when the pins get (re)initialized.

[TesterSAM]

Thank you for your reply and suggestion.

 

The signal is normal since using Debug Mode (skipped the System Memory Bootload) did not contain the Frame error.

 

I tried to execute the  __HAL_RCC_USART2_FORCE_RESET() & __HAL_RCC_USART2_RELEASE_RESET(), and no Frame error in the first UART packet anymore.

 

I checked the operation of these two macros, which reset the RCC & APB peripheral registers. So, I added the HAL_DeInit() before executing the HAL_Init() since the System bootload mode should also initialize I2C & SPI.

 

Although the original issue is fixed by adding the HAL_DeInit(), is that a general operation to call the HAL_DeInit() before HAL_Init() no matter of whether executing the System Bootload Mode or executing the Main Application?

 

[Guenael Cadier]

Hi @TesterSAM 

Glad the workaround helps.
But it is a workaround and to answer your question, there's usually no need to call HAL_DeInit() prior HAL_Init().

Looks like system boot is impacting RX line in different way than running in debugger mode (with a stop on main() breakpoint at start that will introduces a longer delay before Uart reception of course)

Regards