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

[Allen Huffman]

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

[Allen Huffman]

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]

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.

[Allen Huffman]

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?

[Tesla DeLorean]

Posted on March 07, 2018 at 22:03

I looked over the F4 examples (strongly related to F2) and didn't seen any specific examples using DMA and single wire (half-duplex)

Might be worth poking an FAE, or trying to get some attention from the HAL developers as to how they see the mechanics of this working.

The DMA on the F2/F4 should permit for DMA operation on the USART in such a mode, but it might be something you have to engineer or tailor into the HAL paradigm, or do it on the edges.

[Tesla DeLorean]

Posted on March 07, 2018 at 22:10

Cross linking to Lukasz's thread, it is a bit old, but he's still active in the forum and STM32 space, and seems to run into the edge use cases in HAL which are poorly defined.

https://community.st.com/0D50X00009XkhRUSAZ

[Allen Huffman]

Posted on March 07, 2018 at 22:28

Additional details... As I dig further, it seems we are really in full duplex mode, but our software is doing half duplex. We are interfacing to RS485, and we use a pin to enable TX on an external part. On the software side, we see TX/RX like a normal UART, and are working in normal UART full duplex mode. We just have additional code to behave in a half duplex mode.

The odd thing is that UART4 and USART3 seem to be okay, and only USART1 and USART2 (well, at least one of them) act up once we updated to the current HAL.

Based on a post claiming a solution to a similar issue, I manually added calls in the HAL_UART_MspInit() routine to enable interrupts...

    __HAL_UART_ENABLE_IT(huart,UART_IT_RXNE);

    __HAL_UART_ENABLE_IT(huart,UART_IT_TC);

...and then I saw my IRQ breakpoint hit. I thought I was onto something, but I haven't been able to recreate it. I think I am just missing a step that is needed to get the DMA IRQ going.

      -- A

[Allen Huffman]

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]

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...