Skip to main content
Allen Huffman
Allen Huffman
Associate II
February 2, 2018
Question

STM32F2 HAL UART (IRQ?) issues upgrading from 1.1.2 to current

  • February 2, 2018
  • 8 replies
  • 1763 views
Posted on February 02, 2018 at 21:57

We had a legacy F2-based project that was built using the HAL 1.1.2 version:

  * @file    stm32f2xx_hal_uart.h

  * @author  MCD Application Team

  * @version V1.1.2

  * @date    11-December-2015

We updated the HAL to the current version inside the zip (1.2.1 or later - they seem to have removed the version number from the headers with a recent release).

We have been experiencing issues that have been traced back to the UART code. In fact, if we just revere the uart.c and uart.h files to the older 1.1.2, things go back to working.

Release notes indicate some UART changes took place with 1.1.3, and we are trying to figure out what we might be needed to update to work with the current UART HAL.

Any thoughts on where to look?

#dma #usart #half-duplex #irq #1.1.2 #hal #uart
This topic has been closed for replies.

8 replies

Allen Huffman
Allen HuffmanAuthor
Associate II
February 5, 2018
Posted on February 05, 2018 at 17:57

Additional: We also found a change in the Watchdog code we had to fix. If I recall, the older Watchdog did not automatically start, but the new code did. I expect something with the UART config needs to change in my code to get this working.

The largest change seems to be a bunch of new DMA support code.

Tesla DeLorean
Tesla DeLorean
Guru
February 15, 2018
Posted on February 15, 2018 at 01:21

My general recommendation would be to look at some of the USART examples under the HAL trees and see if anything there looks different.

When initializing the USART/UART structure make sure to fill all fields, there may be new ones, or ensure the structure is cleared in auto/local use using ={0};

A merge/diff tool like WinMerge or AraxisMerge might also be helpful to clarify differences.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
Allen Huffman
Allen HuffmanAuthor
Associate II
March 7, 2018
Posted on March 07, 2018 at 21:00

I've been digging through the HAL reference. The two ports that are acting up are both running in half duplex. I have not been able to find a reference example of how this should be setup. My modifications have yet to help.

I have observed that it seems we just never get any IRQs from the half duplex ports, now. I see DMA data coming in from one of the other UARTs just fine, though.

I am expecting there is just some extra step needed now that was not done previously (similar to the change in the Watchdog).

Do you know where I could find a Half Duplex DMA example?

Allen Huffman
Allen HuffmanAuthor
Associate II
March 8, 2018
Posted on March 08, 2018 at 16:05

Did something change with how IRQs have to be processed? On startup, I see our handler for USART1 and USART2 called once, then never again. We also use USART3 and it gets called repeatedly.

Based on other posts here, some have found 'solutions' by adding code to re-enable the IRQ at the end of the routine, and another had some huart flag for READY they had to set, claiming it to be a bug (2016).

Allen Huffman
Allen HuffmanAuthor
Associate II
March 14, 2018
Posted on March 14, 2018 at 15:30

We have located the source of our problem. 'If we knew then what we know now' I could have saved a ton of time.

When this problem first popped up, we did not have a copy of the stock 1.1.2 HAL. We were unable to see if any changes had been made to it. We have now found that there is some UART_DMAError() occurring. Someone had gone in and commented out the HAL_UART_ErrorCallback() in that function in stm32f2xx_hal_uart.c.

The error continues with the current HAL, and commenting out that call makes the code 'work' again, but the underlying issue still remains.

Now we have a real problem to track down. It still looks like we are doing everything the same way the example code does, and the stuff generated by Cube, but we are running in a different mode than the examples so it seems likely that is our issue.

The quest continues...

Terms & ConditionsAccessibility statement