I think that I have found problem in HAL

[Taras Malynovsky]

Posted on May 14, 2018 at 14:02

Dear Sirs/Madams,

I am developing firmware for our device with your STM32F745 microcontroller. I use STM32F7 HAL.

I also use STM32CubeMX (v.4.0) with STM32Cube MCU Package for STM32F7 Series (v.1.0).

I use EWARM (v.8.22) for building and debugging.

I think that I have found problem in HAL.

I need to make duplex transition via USART, where transmitting and receiving don’t have hard synchronization.

I found that TCIE-bit of USART was always set in UART_DMATransmitCplt() but UART_EndTransmit_IT wasn’t called sometimes! If UART_EndTransmit_IT isn’t called – “huart->gState�? will not be set to HAL_UART_STATE_READY. If “huart->gState�? isn’t set to HAL_UART_STATE_READY – new execution of HAL_UART_Transmit_DMA() will always return HAL_BUSY. As the result – transmuting will stop forever. And I really saw it!

I started to investigate this situations and found that TCIE-bit was cleared unexpectedly before USART interrupt was generated…

The bits of USART_CR1 register are set and cleared a few times during transfer data via USART with DMA. HAL_UART_Transmit_DMA-function enables interrupt from DMA. Then this interrupt enables USART-interrupts. And after fixing this Interrupt – it clears itself.

But most of HAL functions aren’t reentrant. Many of them executes changing of peripheral register. For example, TCIE-bit of USART_CR1-register is set from UART_DMATransmitCplt() and is cleared from UART_EndTransmit_IT(). But HAL_UART_Receive_DMA-function changes USART_CR1 too.

It is possible that UART_DMATransmitCplt() or UART_EndTransmit_IT() is executing from Interrupt handler when HAL_UART_Receive_DMA is executing from background.

I can explain my problem that USART_CR1 was been changing as from some interrupt-handler, as from background-function at the same time.

Then I set the same priority for DMA and USART Interrupts and disabled all interrupts during calling HAL_UART_Transmit_DMA() and HAL_UART_Receive_DMA (I could do it with Intrinsic functions of IAR: __disable_interrupt() and __enable_interrupt()). These my actions make impossible to execute different functions which can do the changes of USART_CR1-register.

And I really stoped fixing unexpected behavior!!! But I had to use the same priority for DMA an USART interrupts, and execute start of HAL_UART_Transmit_DMA() and HAL_UART_Receive_DMA during all interrupts were disabled.

Do you know about problem which I found?

Are you think that I do something wrong?

If my assuming is right - HAL limits me in possibility of using peripherals of STM32F7 SPL was more perfect.

My best regards,

Taras

#mto

Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Pavel A.]

Posted on May 14, 2018 at 16:33

Are you trying to receive and transmit simultaneously?

-- pa

[Tesla DeLorean]

Posted on May 14, 2018 at 17:48

>>

Are you trying to receive and transmit simultaneously?

Concurrent RX and TX is an extremely common use case.

>>

If my assuming is right  - HAL limits me in possibility of using peripherals of STM32F745. SPL was more perfect.

HAL makes simple things awkward, and creates complexity and race conditions.

[Taras Malynovsky]

Posted on May 14, 2018 at 16:45

Hello!

I make exchange data via USART between two boards. In general, transferring data in both directions can be executed simultaneously.

Best regards,

Taras

[Pavel A.]

Posted on May 15, 2018 at 01:41

 ,

 ,

For simultaneous TX and RX, the library for F4 has function ,

https://github.com/pavel-a/stm32f4_libs/blob/db5c1ad80b84837d8c52efabd071e1e65811a340/STM32Cube_FW_F4/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_usart.c ♯ L801

 , &, friends.

(don't know why this does not exist for UARTs, or if the same exists for F7 MCUs)

Regards,

-- pa

[Taras Malynovsky]

Posted on May 15, 2018 at 10:46

First of all, thank you very much for answers and proposition.

According to my investigation of

/external-link.jspa?url=https%3A%2F%2Fgithub.com%2Fpavel-a%2Fstm32f4_libs%2Fblob%2Fdb5c1ad80b84837d8c52efabd071e1e65811a340%2FSTM32Cube_FW_F4%2FDrivers%2FSTM32F4xx_HAL_Driver%2FSrc%2Fstm32f4xx_hal_usart.c%23L801

– it is function which starts simultaneous transmitting and receiving of the same size buffers.

My task is to start transmitting and receiving after separate events. One event starts transmitting, the other starts receiving. In general, these receiving and transmitting can be executed simultaneous.

I think that I got problem when transmitting was in progress and receiving was started. There was trying of changing USART_CR1 as from Interrupt-handler and from background-handler. Background-function read and started to modify USART_CR1. Then Interrupt was happened. It also started read, modified and wrote USART_CR1 When execution was returned to background-function, it rewrote USART_CR1 to value which didn’t include Interrupt-handler changes. As re result, changing from Interrupt-handler was lost.

It seems to me that idea of HAL is very good. There is simple migrations form microcontroller to microcontroller. HAL really does the simple actions. But HAL isn’t suitable not only for complex actions but also for actions which didn’t have its realization in HAL. Combings of few realized actions by HAL doesn’t always give the wanted result. My example is confirmation of my previous sentence.

SPL gave realizations of the simplest actions. The user could build his/her own algorithms.

Replacing SPL to HAL had to make developing firmware easer. But it is true only for simple (or for the simplest ) tasks. But as STM32F7, STM32FH7,.. are very powerful microcontrollers – the tasks are not be simple in the most cases. As for me, replacing SPL to HAL by ST made development not easer but too much harder.

Are Community agree with me?

How to convince ST in this?