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

[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

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

[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?

[AvaTar]

Posted on May 15, 2018 at 11:06

Replacing SPL to HAL had to make developing firmware easer.

This is your assumption ... ;)

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.

Very obviously, the target audience is the oblivious beginner, who still shies away from reading datasheets and reference manuals. The Cube generator covers many obvious use cases that such beginners come up with.

And very obviously, Cube-generated code is not fit for commercial purposes. Which makes kind of sense to me. If a semi-literate kid could make competitive software with a few mouse clicks, who would need you ;)

[Taras Malynovsky]

Posted on May 15, 2018 at 11:20

But, as for me, SPL was completely suitable… It was updated sometimes with including Errata recommendations.

I can’t believe, what ST doesn’t know that replacing SPL to HAL make development more hard.

Do you recommend to develop its own library and don’t looking for solving problem from ST?

[AvaTar]

Posted on May 15, 2018 at 12:12

But, as for me, SPL was completely suitable… It was updated sometimes with including Errata recommendations.

For me, too. I'm still using the SPL for F3 and F4 parts.

I can’t believe, what ST doesn’t know that replacing SPL to HAL make development more hard.

I guess it is a trade-off on ST's side. Cube makes the entry easier for mentioned newbies. Commercial users tend to write their own libs anyway. And today's newbies are (supposedly) deciders in 10 years ...

Do you recommend to develop its own library and don’t looking for solving problem from ST?

I would recommend to carefully examine Cube's bug density over time, for the time it exists. And to compare it's structure with your project requirement.

I am not involved in ongoing commercial applications with STM32 MCUs, and will not in the near future - a decision others in my company made.

But since I have to deal with SIL2 requirements, I can assure you Cube would not be considered.

[Taras Malynovsky]

Posted on May 15, 2018 at 12:37

Thank you for your answer.

Our company  uses ST microcontrollers about 10 years. It are STM32F103 and STM32F205. And I am using SPL for them.

Now we are planning to use STM32F7 and STM32H7. There is  no SPL for these lines…

I see, that HAL is unsuitable for big project!

What about LL?

I haven’t still investigated it. Is it reason to investigate LL as a library for commercial project?

Or LL is the same unsuitable as HAL?