How to handle changes in HAL when regenerating

[JDWBE]

Hi

Most of you are using the HAL library, if you want to do something standard and if it works out of the box, what was generated, it speeds up your project. Sometimes it is not the case… so we need to adapt the HAL to make it work. Now the main issue, when we need to regenerate the project al the changes are gone and we need to change everything again by hand… Maybe this sound familiar to you?

It this is the case how did you handle this? Patch file, list al the changes and do it again by hand?

@ST, is it possible to support user code blocks added by the user and not only where CUBE decide to add. Or make it possible to generate / add code for some specific parts/ hardware? For example, I want to add or change UARTx, there is no need to update the SPI code…

[Karl Yamashita]

Create a new c/h file like the particular file you’re trying to modify and add like “_alt” to the file name. Then copy the function into your new file and add “_alt” to the function name. Make your changes there.

Instead of calling the actual HAL function, you call your “HAL_xxx_alt” function. Even when regenerating the project, it won’t touch your new file/function.

[Andrew Neil]

I’m not clear on what you’re describing here:

 

we need to adapt the HAL to make it work

Do you mean actually modifying the HAL files, or just modifying the stuff generated by CubeMX ?

 

when we need to regenerate the project al the changes are gone

I don’t think that regenerating will restore HAL files - as the name suggests, it just recreates the things generated by CubeMX.

But CubeMX provides “User Sections” within its generated files - that’s where you put code that you want to be preserved.

 

For example, I want to add or change UARTx, there is no need to update the SPI code…

You know you can get CubeMX to generate separate files for each peripheral ?

[JDWBE]

Do you mean actually modifying the HAL files, or just modifying the stuff generated by CubeMX ?

Just modified the code generated by CubeMX, for example the low level ethernet driver.

But CubeMX provides “User Sections” within its generated files - that’s where you put code that you want to be preserved.

I know but sometimes i need to change something (ETH driver) there are no user section available. 

You know you can get CubeMX to generate separate files for each peripheral ?

Yes, i know.

[Pavel A.]

If your changes in the ST library are small or you’re experimenting - then ​@Karl Yamashita offered a good advise.

If the changes are permanent (like a patch to fix a bug in the library) - then you likely need to fork the library and maintain your own fork. This is a complication, but not a rocket science.

1. When you generate a project, use “Add necessary library files as reference in the toolchain project configuration file” option.  Then the library files won’t be copied into your project, instead the project will refer to the files in the “Cube repository”.  
2. Make your changes in the “repository” and save them in your version control (as a fork or set of patches… whatever you prefer).
3. Next time when Cube re-generates  the project, or generates new projects, your changes will be automatically used and not overwritten.

Note that the ST libraries are available on github, you can clone them from github and fork from there. And pull fixes and updates as they are released.

[David Littell]

​@Pavel A.’s approach is much more sophisticated and probably the overall best option.  I was burdened with a “thou shalt not modify the original HAL sources used by CubeMX” mandate so I used the post-code-generation patch method.  It was a bit cumbersome but did allow me to get on with the job.