cancel
Showing results for 
Search instead for 
Did you mean: 

STM32CubeMX IDE issue. Throws warning when using macros

Rajeev Arora
Senior

Hello,

Microcontroller used STM32H753BI

Issue: STM32CubeMX 6.0.0 Macro concerns

Case Number informed by ST (internal community): 00112804

Issue details below:

Please check the attached files.

The STM32CubeMX 6.0.1 now allows adding alphanumeric values constant values, after I had requested for this. This feature was not available with STM32CubeMX 5.6.1

Initial behavior when macros are declared and used:

Some examples of macros that will get added to main.c as a result of adding the macros under USER CONSTANTS are:

#define MaxStdFIFOs (u8CAN1MaxStandardFIFO)
 
#define RS485RCUBaudRate (47600UL)

in the above example u8CAN1MaxStandardFIFO is an unsigned char variable, which is defined only in my code and is also appropriately externed.

Once I add the macro and its alphanumeric value, I am able to use the macro as value for USART3 baudrate, Defining some other values etc.

The code also generates without any concern until the project is not closed.

Observation & Concerns:

Whenever the IOC file is opened again and I try to regenerate the code, the STM32CubeMX 6.0.0 for no reason start THROWING WARNING about the Drivers which use the macros similar to the ones shared above. Please refer to snippet STM32CubeMX-6.0.0-Code-generation-concern.png for details.

Also refer to STM32CubeMX-6.0.0-macro-declaration.png to refer to some macros that have been declared. Please check the items encircled with red line.

Also please refer to Initially-allowed-using-macro-but-on-repoening-IOC-shows-a-red-cross.png file. Please observe the red cross marks.

Requesting Fixes:

The C code and the associated allows putting values assigned to macros in brackets. It also allows adding UL at the end of a number so as to inform that the number must be treated as unsigned long. Similarly a macro / name as an alias for a variable.

The STM32CubeMX should not through errors for above implementations when requested / added with help of STM32CubeMX.

Please help.

Thanks,

Rajeev

5 REPLIES 5
TDK
Guru

With such little information given, I'm not surprised you're not getting a response.

If you include enough information about what's happening, it's likely someone can help. If you omit details, it's less likely. This is a user forum, it's not a direct line to ST.

If you feel a post has answered your question, please click "Accept as Solution".
Rajeev Arora
Senior

Hello,

Please check the attached files.

The STM32CubeMX 6.0.1 now allows adding alphanumeric values constant values, after I had requested for this. This feature was not available with STM32CubeMX 5.6.1

Initial behavior when macros are declared and used:

Some examples of macros that will get added to main.c as a result of adding the macros under USER CONSTANTS are:

#define MaxStdFIFOs u8CAN1MaxStandardFIFO

#define RS485RCUBaudRate (47600UL)

in the above example u8CAN1MaxStandardFIFO is an unsigned char variable, which is defined only in my code and is also appropriately externed.

Once I add the macro and its alphanumeric value, I am able to use the macro as value for USART3 baudrate, Defining some other values etc.

The code also generates without any concern until the project is not closed.

Observation & Concerns:

Whenever the IOC file is opened again and I try to regenerate the code, the STM32CubeMX 6.0.0 for no reason start THROWING WARNING about the Drivers which use the macros similar to the ones shared above. Please refer to snippet STM32CubeMX-6.0.0-Code-generation-concern.png for details.

Also refer to STM32CubeMX-6.0.0-macro-declaration.png to refer to some macros that have been declared. Please check the items encircled with red line.

Also please refer to Initially-allowed-using-macro-but-on-repoening-IOC-shows-a-red-cross.png file. Please observe the red cross marks.

Requesting Fixes:

The C code and the associated allows putting values assigned to macros in brackets. It also allows adding UL at the end of a number so as to inform that the number must be treated as unsigned long. Similarly a macro / name as an alias for a variable.

The STM32CubeMX should not through errors for above implementations when requested / added with help of STM32CubeMX.

Please help.

Thanks,

Rajeev

@TDK​ 

I've added details to the concern that I raised.

Regards,

Rajeev

TDK
Guru

Not sure there's a bug here. CubeMX is set up to take a numeric value for the baud rate. You're feeding it a user defined macro. It happens to expand to an integer, but CubeMX doesn't know that. Sounds like a feature request more than a bug report.

0693W000004IQWKQA4.png

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

Hello @TDK​ 

The reason I reported this as an issue is because there are two different behaviors shown by STM32CubeMX.

The correct behavior is shown by STM32CubeMX shows when the IOC file is open and user first adds the macro (like dRS485PowerSupplyBaudRate) and then assigns the macro to one of the property (i.e. to Baud Rate). If the IOC file is saved and code is generated without closing the project, then STM32CubeMX does not throw any error.

The same STM32CubeMX version shows a different and incorrect behavior when the project is closed and reopened. Now:

  1. if one has an already defined macro, which one wants to assign to a property, the STM32CubeMX will not let you assign the macro name to the property. (This is different from behavior stated earlier).
  2. If one generates code, the STM32CubeMX throws warning for Devices which have macro names assigned to properties. (Again this behavior is different from earlier stated behavior).

My concern is that when the STM32CubeMX allows me to add Macros and then assign them to a property, why can it not leave them as is and:

  1. Allow me use / assign the existing macro names even after I reopen project.
  2. Inform in the warning about which macro it is considering to be a concern, so that I may decide on whether to disregard the warning or abort code generation.

Regards,

Rajeev