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.