Preprocessor symbols not handled correctly when compiling via IDE in Windows instead of command line

[Eqqm4n]

Operating System

Windows 11

Board

all

Firmware

n/a

What happened ?

Tinyusb appears to expect symbol CFG_TUSB_MCU to be set via command line or some make file as a #define for it isn't present in the source files. This may be fine when compiling from a shell prompt via Linux but causes issues when compiling the code as I do via an IDE in Windows (specifically, Segger Embedded Studio).

In the project settings I have a CFG_TUSB_MCU=OPT_MCU_STM32F4 entry that gets me past the errors where CFG_TUSB_MCU is not defined, however, this doesn't mean everything is correct even though the code compiled with zero errors or warnings. In file dwc2_stm32.h the #if ... #elif chains don't evaluate correctly because none of the OPT_MCU symbols have been defined yet. To correct this issue I had to add #include "tusb_option.h" to the start of the file as its include chain doesn't have that in there. I'm left wondering how many other things in the code might also be incorrect because of this issue. It might be advisable to make sure more of these files route their headers up to tusb_config.h to cover this and ensure that there are no symbols being defined outside the scope of the source files.

How to reproduce ?

Compile the code via an IDE instead of from a shell prompt.

Debug Log as txt file (LOG/CFG_TUSB_DEBUG=2)

n/a.

Screenshots

No response

I have checked existing issues, dicussion and documentation

• I confirm I have checked existing issues, dicussion and documentation.

[HiFiPhile]

No such issue, just Embedded Studio can't handle code highlighting correctly, so it appears STM32F1 is chosen.

[Eqqm4n]

Can't disagree more with this assessment. The next failure I find in SES' symbol highlighting will be the first one. You can sit there and add & remove symbols on the fly and the highlighting will correctly update even if you don't save the file.

Also, if you read what was written you will find absolutely NO mention of the highlighting, so it's not clear why that was even brought up. All of the points I raised have nothing to do with how SES or any IDE is highlighting code.

Once again, the header path for dwc2_stm32.h doesn't include tusb_option.h, so if files using that header are compiled before a file invoking tusb_option.h, the OPT_MCU symbols will not be defined causing those files to compile incorrectly.

[HiFiPhile]

The next failure I find in SES' symbol highlighting will be the first one. You can sit there and add & remove symbols on the fly and the highlighting will correctly update even if you don't save the file.

CFG_TUSB_MCU=OPT_MCU_STM32C0 but F1 is highlighted:

Once again, the header path for dwc2_stm32.h doesn't include tusb_option.h

dwc2_stm32.h is used by dwc2_common.h in which tusb_option.h is included:

tinyusb/src/portable/synopsys/dwc2/dwc2_common.h

Line 30 in 2495563

#include "common/tusb_common.h"

so if files using that header are compiled before a file invoking tusb_option.h, the OPT_MCU symbols will not be defined causing those files to compile incorrectly.

Header files should NOT be compiled directly !

https://stackoverflow.com/questions/17416719/do-i-need-to-compile-the-header-files-in-a-c-program

---

TinyUSB is supported by all major IDEs like IAR, MDK ARM, SES, STM32CubeIDE, MCUXpresso, etc.

[Eqqm4n]

Thank you for the clarifications.

The reason you're seeing that apparent "error" is that even though CFG_TUSB_MCU=OPT_MCU_STM32C0 is set, none of the OPT_MCU symbols exist at that stage. The preprocessor will replace CFG_TUSB_MCU with OPT_MCU_STM32C0, so the expression you have highlighted there equates to "#if OPT_MCU_STM32C0 == OPT_MCU_STM32F1". As none of the OPT_MCU symbols exist yet, this is "#if (not defined) == (not defined)", so the highlighting is correct. If you add #include "tusb_option.h" to dwc2_stm32.h, this clears up immediately.

I clearly said "if files USING that header are compiled..." not "if header files are compiled", so it's not clear to me why you think I might be compiling header files directly by themselves.

This would seem to be "working" because it's dwc2_common.c that invokes the chain of header files leading up to dwc2_stm32.h by including dwc2_common.h, but notice that dwc2_common.c also includes tusb_option.h before it does this. So this chain of symbol definitions breaks down if the order of #include listings gets modified to swap this order (maybe even somebody maintaining TinyUSB on accident does this, trying to reorganize the code). Given that dwc2_stm32.h will not preprocess correctly if the OPT_MCU symbols don't exist yet, it seems eminently sensible for this file not to just assume a #include order elsewhere in the project is correct and just also do its own #include "tusb_option.h".

Thank you again for your time reviewing this issue.