Issue with MACROs after generating code using STM32CubeMX

[DDeba.1]

Hi, 

I am using the STM32CubeMX ver 6.13.0 to generate a USB-PD DRP application. After generating the code following this procedure for custom boards (https://wiki.stmicroelectronics.cn/stm32mcu/wiki/STM32StepByStep:Getting_started_with_USB-Power_Delivery_Dual_Role) I see that the file "usbpd_pwr_if.c" is defining the following macro "#define __USBPD_PWR_IF_C" first thing, than including the necessary header files. One of the header files, "usbpd_pdo_defs.h", is using the __USBPD_PWR_IF_C to check if there is the need to initialize the list of SRC/SNK PDOs or get them as externs.  The issue is that even though the __USBPD_PWR_IF_C is defined and the "usbpd_pdo_defs.h" header is included after the definition, the "usbpd_pdo_defs.h" header file is not seeing the definition and is enabling the necessary code as if the macro __USBPD_PWR_IF_C was not defined.

Any possible reasons for this behaviour?

Thanks

[TDK]

Try it on the latest CubeMX version and include the IOC file that shows the issue.

[DDeba.1]

Hi TDK,

I regenerated using the latest CubeMX but gave the same result. While __USBPD_PWR_IF_C is defined in usbpd_dpm_user.c, the usbpd_pdo_defs.h is not finding it as can be seen from the image below. I included the IOC file as requested.

Note: In my project, I disabled the GUI_INTERFACE, TRACER_EMB and RTOS as I won't be using them. Moreover, in the X-CUBE-TCPP section, I unchecked "Board Part tcpp0203" as this is a custom board which wont be using it. I left "Device USBPD Application" checked in order to populate the xx_user.c  files with the necessary code for USBPD. 

[FBL]

Hi @DDeba.1 

An internal ticket is submitted to dedicated team for fixes 206191.

[Softronic Solutions]

Dear @FBL ,

In addition to @DDeba.1 findings I like to add related topic.

One could add the #define __USB_PWR_IF_C as symbol for the compiler as below.

So that the compiler will compile the variables in the uspd_pdo_defs.h file and no longer makes use of the externs.

But then the linker start complaining about multiply definitions in h file and object file.

Meaning something is definitely not correctly implemented in the CubeMX generated skeleton code.

I hope you can internally escalate this support ticket, because this is definitely not the first time issue like this happen and  we are loosing precious time again and again. Alternatively you could also provide us the USBPD stack as open source so we can self support.

With regards. 

[FBL]

Dear @Softronic Solutions

I agree, adding __USB_PWR_IF_C as symbol for the compiler preprocessor would help solving the issue to compile variables in uspd_pdo_defs and avoid using "extern" in multiple files. Your feedback is much appreciated and has been shared internally with the dedicated team.

[Bob S]

DISCLAIMER: I have no experience specifically with the USB PD code, this is a general response

But - if the include files are only supposed to see _USB_PWR_IF_C defined when they are included from "usbpd_pwr_if.c", then defining that in the compiler settings will (probably) break something.  Unless "uspd_pdo_defs.h" is only ever included from that one file.

Typically when an issue like this pops up the real problem is that the include file is somehow getting included BEFORE that value is defined.  The include guards in the include files prevent it from being parsed a 2nd time.  To track this down, you can temporarily add a new define at the top of "usbpd_pwr_if.c" (insert as the 1st line in the file) something like

#define THIS_SHOULD_BE_DEFINED  1

Then add a check in the offending include file (uspd_pdo_defs.h) BEFORE the include guards (i.e. as the first lines in the file):

#if defined(THIS_SHOULD_BE_DEFINED) && !defined(_USB_PWR_IF_C)
   #error NOT DEFINED
#endif

If the error gets triggered, the compiler output will list the include file tree that led to "uspd_pdo_defs.h" being included prematurely.

[FBL]

Thank you @Bob S for the suggestion. It is more likely due to the way the files are being included and the order in which they are processed.