Error/Debug Messages in .bin file

Development Platforms
,
1

Hi All,

I’m using PlatformIO to generate some code for an ESP32 Huzzah Feather and in the generated .bin file there are references to error/warning messages which don’t seem to affect the compilation of the project, but look slightly concerning nonetheless. As an example:

@C:/users/“myusername”/.platformio/packages/framework-arduinoespressif32/cores/esp32/esp32-hal-gpio.c [%6u][E][%s:%u] %s(): Invalid pin selected

There’s also messages in there about the clock frequency that look like they should be written to a terminal:

[%6u][E][%s:%u] %s(): Bad frequency: %u MHz! Options are: 240, 160, 80, %u and %u MHz

Is there a way to turn these off or prevent them being written to the .bin? I’m not sure what purpose they serve and we need to compare source files built by different users to check for consistency and having the user’s name in there prevents this. I’ve included my PlatformIO setting below.

[env:featheresp32]
platform = espressif32
board = featheresp32
framework = arduino
monitor_speed = 115200
extra_scripts = pre:EPS_Exporter.py
custom_eps_version = 01
custom_eps_number = 000001
build_flags =
    -D EPS_REVISION=${this.custom_eps_version}
build_type = release

Many thanks,
Owen

2

Then set the debug level to none per docs.

The default is “error”, hence all log_e() logs get through.

3

Thanks Maximilian. I had tried that option but it hadn’t cleared things up completely. I’m still getting the following in the .bin if there is anything else to try?

@"(Cannot use SET_PERI_REG_MASK for DPORT registers use DPORT_SET_PERI_REG_MASK)" && (!((((GPIO_PIN_MUX_REG[gpio_num])) >= 0x3ff00000) && ((GPIO_PIN_MUX_REG[gpio_num])) <= 0x3ff13FFC))
C:/users/"myusername"/.platformio/packages/framework-arduinoespressif32/tools/sdk/esp32/include/hal/esp32/include/hal/gpio_ll.h
gpio_ll_input_enable

It seems related to the attachInterrupt function as if I comment this out the C:/users/“myusername”/.platformio/packages/framework-arduinoespressif32/tools/sdk part of the path disappears. It’s currently being used in the following form:

attachInterrupt(digitalPinToInterrupt(pinNumber), isr, RISING);

Many thanks,
Owen

4

Yeah that one’s from

and is not due to “logs”, but static asserts.

Sadly that specific headerfile does not have the capability to disable its assertions, but maybe if all asserts come from C and not C++, the upper path is chosen with assert(), which may listen to the NDEBUG (“no debug”) macro per this as its “disable switch”.

So, you should first try adding -DNDEBUG to your build flags.

Alternatively, as the basically ultra hack, you can globally define the include guard macro __ESP_ASSERT_H__ to make it think the header is already included, then redefine all externally used macros (TRY_STATIC_ASSERT) to empty macros swallowing all of their arguments. I’m not sure how this would work shell-escape wise, but something along the lines of

build_flags = -D__ESP_ASSERT_H__ -DTRY_STATIC_ASSERT\(...\)

(aka, a variadic macro expanding to nothing)

5

On a completely different not, if it’s just the __FILE__ macro that’s basically showing your path, you may also just give it

build_flags =
   -fmacro-prefix-map=__FILE__=.

per this. This would allow you to still have runtime-checks and error messages, with just your path info removed.

6

Thank you for the advice, I managed to solve it with a combination of:

    -DNDEBUG
    -DCORE_DEBUG_LEVEL=0

in the .ini file. I also found that if I switched to using:

gpio_install_isr_service(ESP_INTR_FLAG_EDGE);

gpio_set_intr_type((gpio_num_t)pinNumber, GPIO_INTR_POSEDGE);
gpio_isr_handler_add((gpio_num_t)pinNumber, isr, NULL);

it made the error disappear but I’ll use the .ini file solution as this is preferable.

Many thanks,
Owen