Custom User Code Sections

[dmocom]

In many cases, especially for middleware, it may be necessary to extend the code generated by CubeMX.

Since not all files have sections that are untouched by the code generator or some places inside a file are missing those user code sections, I'm often in the need of a feature that would allow to add my own sections by adding a comment such as

 

/* USER CODE BEGIN */

/* USER CODE END */

 

to my source file. Unfortunately, those sections are overwritten as soon as the code generator gets triggered again.

Would it be possible to add this feature?

How does the code generator currently handle those sections anyway if not looking for the specific comments (since adding my own user code comments does not work)?

[Karl Yamashita]

Just add another custom c/h file that you can write your own code in and not worry about CubeMX touching the file.

 

I do that with main.c now because 1 time I spent about 2 hours writing code within the USER CODE section. At one point I made some changes to some peripherals and when I generated code, the program unfortunately locked up and it corrupted the file. I could not open the file at all in CubeMX or in a text editor and so I lost all my code. The USER CODE section is a nice idea and I liked it a lot. But when it bit me that 1 time, I now stay away from using it 

 

So now as a habit, I create PollingRoutine.c/h files. So now the only two things that I write in main.c is a call to PollingInit before the while loop and PollingRoutine inside the while loop. 

 

For things like peripherals, I create a file like ADC_Handler.c/h, I2C_Handler.c/h, etc., and write code in those files.

 

 

[dmocom]

Out team has already discussed similar approaches, but we would like to stay away from essentially duplicating all generated files since the project is large and uses a lot of middleware, sometimes generating thousands of lines of code itself in a dozen source files.

When the ioc-file (from CubeMX) is modified and re-generates code, see the changes in git of course. However, it is tedious to change these parts back when the solution would be as simple as allowing custom user code sections.

[Karl Yamashita]

If you create your own c/h files, how is CubeMX going to generate duplicate files? 

[unsigned_char_array]

I would like this feature as well.

There are workarounds though. With macro tricks you can modify code outside of the user code section. It may not be the prettiest, but it works. I have some examples for function substitution here: https://github.com/ChrisIdema/c_macro_tricks/tree/master/function_substitution . Let me know if it works for you. If not please post your source file (optionally stripped down a bit) to show what code you would like to modify.

[dmocom]

A workaround is fine as long as custom user sections are not implemented or even considered.

But in my case, even those are not sufficient. More specifically, I want to change two defines in the sdmmc low level header file (stm32h7xx_ll_sdmmc.h):

#ifndef SDMMC_DATATIMEOUT
#define SDMMC_DATATIMEOUT ((uint32_t)12345)

#define SDMMC_CMDTIMEOUT ((uint32_t)6789) 

For SDMMC_DATATIMEOUT the #ifndef directive is provided so that the user can define the value beforehand. This seems like a good idea to prevent the need of custom user sections in those cases, but unfortunately this header (stm32h7xx_ll_sdmmc.h) is included (by the code generator) before the user defines that are set in CubeMX appear in main.h. The user section comment for the header-doc in main.h can be misused for this case though, but this makes some user defines via CubeMX obsolete.

For SDMMC_CMDTIMEOUT there is no way to change it via CubeMX, not even a workaround other than overwriting the generated files and taking care in future updates that the overwritten value does not get staged in git (or some other version control).

It's a little frustrating that there is no way to consistently handle changes for generated code in STs development environment.

[unsigned_char_array]

You can simply add a global define to your build settings:

 

For SDMMC_CMDTIMEOUT it is more challenging. One solution is to include the c file in another c file and exclude the original c file from build. Then you can add some macros at the beginning and end of the source code without modifying the file. Or simply make a copy of the c file and rename it and then exclude the original from build.

[ADunc.1]

+1 for me on custom user code sections.  Or some way you can prevent STM32CubeMX from re-writing over your changes, while still allowing it to generate the rest of the file in case over time there are improvements or errata fixes.

It is particularly useful when you want to alter low level driver code or when the generated code just doesn't quite match your application or hardware requirements.  The STM32CubeMX code is very generic but usually gets you 99% of the way there.  But that last 1% can be tedious if there is no USER CODE section where you need it.