cancel
Showing results for 
Search instead for 
Did you mean: 

How to use old HAL library in CubeIDE

Lgarb.1
Associate II

Hi, I have a problem using stm32f722 uC with HAL 1.16.0 and 1.16.1

I write a simple UART send project and test it with an oscilloscope (becouse it doesn't work with the target device) and discover that HAL_UART_Transmit is sending correct bytes while HAL_UART_Transmit_DMA is not. The last one corrupt a couple of byte.

So I want to check it's a bug on the library (trying old versions) or it's another problem with my implementation.

So, how could I choose an old HAL library (I have 1.15 installed) on STM32CubeIDE project generation?

Thank

9 REPLIES 9
MM..1
Chief II

In STM32CubeIDE its very simple. Open ioc and in software packs manager download any version in list. After downloaded in project manager select firmware version to use.

And for your trouble DMA is reported in latest MX bad order generated in code. Try change order in main MX_DMA_Init place up for example after GPIO.

WTF!!!!!! I didn't know about that problem with generated code!!!!! I spend so many hours on it!!!!!!

I've download the firmware in project manager, but I can't choose 1.15, the combobox list only 1.16.0 and 1.16.1

TDK
Guru

What is the project manager? Do you see the package installed in the package list within CubeMX?

If you feel a post has answered your question, please click "Accept as Solution".
Lgarb.1
Associate II

On the IDE I go to File->New->STM32Project

Choose STM32F722RE CPU

Then write a name to the project and on the next screen I have to choose firmware package, but I have 1.16.0 and 1.16.1.

But when I go to Help->Manage Embedded software package I have checked 1.15.0, 1.16.0 and 1.16.1

It's not working.

It's so weird, I can use HAL_UART_Transmit_DMA on the main function, but as soon as I move it to another function (inside of the same main.c) it stop working.

Lgarb.1
Associate II

Ok, I found the problem. I can't use local variable (inside of a function) for transmit buffer. I have to declare it at file level, that way it is working ok.

Is it a bug or is it the correct way to work with DMA transfer?

That’s how DMA works. The data needs to be valid until the transfer is over.
If you feel a post has answered your question, please click "Accept as Solution".
Lgarb.1
Associate II

aggg, what a noob am I !!! sorry, my mistake.

I'm communicating with a smart servo. I'm sending some command and expecting some answer. Could I call HAL_UART_Transmit_DMA and then HAL_UART_Receive_DMA? Or should I put HAL_UART_Receive_DMA on TxCpltCallBack?

So using a different HAL library is no longer a question. Good.

HAL_UART_Receive_DMA and HAL_UART_Transmit_DMA can run in parallel. If you start receive before transmit, you avoid the time window when the device starts sending its reply before RX is enabled. Try this.

Note, if your servos are RS-485 then use a different init call: HAL_RS485Ex_Init