undefined reference to `gpio_new_flex_glitch_filter' (IDFGH-10710)

[stccff]

Answers checklist.

• [X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• [X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• [X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.1

Operating System used.

Windows

How did you build your project?

VS Code IDE

If you are using Windows, please specify command line type.

None

What is the expected behavior?

build success

What is the actual behavior?

undefined reference to `gpio_new_flex_glitch_filter'

Steps to reproduce.

1. call C interface "gpio_new_flex_glitch_filter"
2. build

Build or installation Logs.

[1/9] Performing build step for 'bootloader'
[1/1] cmd.exe /C "cd /D D:\DEV\esp\my_workspace\zelda_guardian_robot\build\bootloader\esp-idf\esptool_py && d:\DEV\esp\python_env\idf5.1_py3.11_env\Scripts\python.exe D:/DEV/esp/esp-idf/components/partition_table/check_sizes.py --offset 0x8000 bootloader 0x0 D:/DEV/esp/my_workspace/zelda_guardian_robot/build/bootloader/bootloader.bin"
Bootloader binary size 0x5680 bytes. 0x2980 bytes (32%) free.
[5/7] Linking CXX executable main.elf
FAILED: main.elf 
cmd.exe /C "cd . && D:\DEV\esp\tools\xtensa-esp32s3-elf\esp-12.2.0_20230208\xtensa-esp32s3-elf\bin\xtensa-esp32s3-elf-g++.exe -mlongcalls -Wl,--cref -Wl,--defsym=IDF_TARGET_ESP32S3=0 -Wl,--Map=D:/DEV/esp/my_workspace/zelda_guardian_robot/build/main.map -Wl,--no-warn-rwx-segments -fno-rtti -fno-lto -Wl,--gc-sections -Wl,--warn-common -T esp32s3.peripherals.ld -T esp32s3.rom.ld -T esp32s3.rom.api.ld -T esp32s3.rom.libgcc.ld -T esp32s3.rom.newlib.ld -T esp32s3.rom.version.ld -T memory.ld -T sections.ld @CMakeFiles\main.elf.rsp -o main.elf  && cd ."
d:/dev/esp/tools/xtensa-esp32s3-elf/esp-12.2.0_20230208/xtensa-esp32s3-elf/bin/../lib/gcc/xtensa-esp32s3-elf/12.2.0/../../../../xtensa-esp32s3-elf/bin/ld.exe: esp-idf/main/libmain.a(pwr_ctrl.c.obj):(.literal.pwr_ctrl_init+0x3c): undefined reference to `gpio_new_flex_glitch_filter'
d:/dev/esp/tools/xtensa-esp32s3-elf/esp-12.2.0_20230208/xtensa-esp32s3-elf/bin/../lib/gcc/xtensa-esp32s3-elf/12.2.0/../../../../xtensa-esp32s3-elf/bin/ld.exe: esp-idf/main/libmain.a(pwr_ctrl.c.obj): in function `pwr_ctrl_init':
D:/DEV/esp/my_workspace/zelda_guardian_robot/main/pwr_ctrl/pwr_ctrl.c:154: undefined reference to `gpio_new_flex_glitch_filter'
collect2.exe: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

 *  终端进程“C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe -Command ninja ”已终止，退出代码: 1。

More Information.

No response

[suda-morris]

Thanks for reporting. esp32-s3 doesn't support this hardware feature. But you can use another simplified filter "gpio_new_pin_glitch_filter" on esp32s3. https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/api-reference/peripherals/gpio.html#gpio-glitch-filter

[aavogt]

From the esp32c3 api I also thought I could use the flex glitch filter, but I get the same linker error as above. Idf can try to compile gpio_flex_glitch_filter.c if I add set(CONFIG_SOC_GPIO_FLEX_GLITCH_FILTER NUM 1) to my CMakeLists.txt. Then I get another error saying that the "hal/gpio_glitch_filter_ll.h" is only for esp32c6 or esp32h2.

(A) The documentation could be improved by having the following part of gpio.rst show up even with IDF_TARGET_FLEX_GLITCH_FILTER_NUM==0:

{IDF_TARGET_NAME} provides {IDF_TARGET_FLEX_GLITCH_FILTER_NUM} flexible glitch filters, whose duration is configurable. We refer to this kind of filter as flex flitch filter. Each of them can be applied to any input GPIO. However, applying multiple filters to the same GPIO does not make difference from one. You can create the filter handle by calling :cpp:func:gpio_new_flex_glitch_filter. All the configurations for a flexible glitch filter are listed in the :cpp:type:gpio_flex_glitch_filter_config_t structure.

Or (B) conditionally remove gpio_new_flex_glitch_filter from the documentation. I think it should still be in the header, but perhaps it can have a pragma/attribute saying that the current target has no flex glitch filter. Either option would be better than the current linker error.