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.

[Tesla DeLorean]

Posted on May 15, 2018 at 13:10

>>Are Community agree with me? How to convince ST in this?

My position on HAL vs SPL are well known and long stated. I gave up and work on my own stuff now.

[Tesla DeLorean]

Posted on May 15, 2018 at 13:22

LL was provided as something closer to SPL.

I typically take portions of the HAL that work the way I want, and recode/simplify the stuff that doesn't.

>>

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

Migrated F1 stuff to F2/F4, all staying in SPL, not plans to port

New stuff looking at L0, L4, F7 and H7, proof-of-concept done with a mix of HAL, register level.

[Taras Malynovsky]

Posted on May 15, 2018 at 13:24

Thank you for your opinion.

Whit is your opinion 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?

[AvaTar]

Posted on May 15, 2018 at 14:05

Similar to Clive.

Sometimes (for a F746 project) investigated Cube projects or LL sources, and recoded what I needed.

HAL/Cube might be good for prototypes / proof-of-concept projects - if you get it to work in a reasonable time.

ST seems to churn out new silicon much faster than the Cube team can integrate it. And there seems no much difference between HAL and LL. I have not had the impression of a decreasing bug density lastly, but perhaps I'm wrong.

[Alan Chambers]

Posted on May 15, 2018 at 15:46

When time allows, I'll be switching to register only. Though I am a fan of well-written libraries, I think I would rather have code that more directly maps onto the datasheet and reference manual. In practice, the register twiddling is a small fraction of my applications, in any case, and is always encapsulated behind an API, so it hardly matters whether it is written in SPL, HAL, LL or none of these.

[tbulsink9]

Posted on May 17, 2018 at 10:03

From what i can say, the LL is a newer version of the SPL, and what HAL should have been. Especially if you define FULL_LL_DRIVER (or something along those lines)  you get something that looks a lot like SPL. For me, the LL is what is going to be the most helpful in the long run (but only because ST stopped making SPL for newer parts)

There are a few challenges though:

- Not all stuff is supported (yet) by LL. So if you code LL stuff now, you probably still need some HAL stuff. I even think that LL headers include HAL headers which to me seems like it's the wrong way around.

- LL is newer. You get newer bugs. And you might even get new old bugs. Who knows.

- Probably the LL has the same problems as the SPL did. When that got launched people said it was bloated (eyes of the beholder and all that). Also, the HAL works around bugs in the hardware which the SPL/LL did/does not. When something does not work as expected (according to datasheet) i find myself looking at HAL code to see what the hell i am doing wrong. Then you find things that ST tried to hide by creating the HAL.

I'm curious if they ever get the I2C stuff right ......