Testing out the ‘blufi’ example led to a lot of linking problems. The project compiles fine but can’t link (just to take some of the errors see below). I guess it’s something trivial, but I have apparently gone “blind”, it seems to be related to the Bluetooth component. What am I missing here, some special menu config perhaps?
c:/users/niels/.platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld.exe: .pio\build\nodemcu-32s\src\blufi_example_main.o:(.literal.example_event_callback+0x84): undefined reference to `esp_blufi_adv_start'
c:/users/niels/.platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld.exe: .pio\build\nodemcu-32s\src\blufi_example_main.o:(.literal.example_event_callback+0x88): undefined reference to `esp_blufi_adv_stop'
c:/users/niels/.platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld.exe: .pio\build\nodemcu-32s\src\blufi_example_main.o:(.literal.example_event_callback+0x98): undefined reference to `esp_blufi_send_error_info'
c:/users/niels/.platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld.exe: .pio\build\nodemcu-32s\src\blufi_example_main.o:(.literal.example_event_callback+0xa4): undefined reference to `esp_blufi_send_wifi_conn_report'
c:/users/niels/.platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld.exe: .pio\build\nodemcu-32s\src\blufi_example_main.o:(.literal.example_event_callback+0xa8): undefined reference to `esp_blufi_disconnect'
.
.
.
@maxgerhardt Thanks for the support!
I can’t seem to find that setting in menuconfig and the example doesn’t have a Kconfig file that I need to add to the project in order to get this setting? Adding the setting directly to the sdkconfig file doesn’t help on the linkling problem either.
Reading the referenced github issue doesn’t seem to relate to my issue.
Okay I found it in menuconfig - and I learned something new, the ‘/’ function, thanks!
Although it helped with some of the link problems, now it seems to have to do with security stuff. I wonder what setting I am missing now and need to search for?
c:/users/niels/.platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld.exe: .pio\build\nodemcu-32s\src\blufi_security.o:(.literal.blufi_dh_negotiate_data_handler+0x24): undefined reference to `mbedtls_aes_setkey_enc'
c:/users/niels/.platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld.exe: .pio\build\nodemcu-32s\src\blufi_security.o:(.literal.blufi_aes_encrypt+0x0): undefined reference to `mbedtls_aes_crypt_cfb128'
c:/users/niels/.platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld.exe: .pio\build\nodemcu-32s\src\blufi_security.o:(.literal.blufi_security_init+0x0): undefined reference to `mbedtls_aes_init'
c:/users/niels/.platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld.exe: .pio\build\nodemcu-32s\src\blufi_security.o:(.literal.blufi_security_deinit+0x0): undefined reference to `mbedtls_aes_free'
c:/users/niels/.platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld.exe: .pio\build\nodemcu-32s\src\blufi_security.o: in function `blufi_dh_negotiate_data_handler':
C:\Users\niels\Documents\PlatformIO\Projects\BlueConfig/src/blufi_security.c:112: undefined reference to `mbedtls_aes_setkey_enc'
.
.
.
Make sure you have the appropriate mbedtls functions turned on too:
But actually, if that option was turned on, it shows that most likely you didn’t copy over or regenerate the sdkconfig files from the example. They already configure ESP-IDF exactly how the example needs it.
So to avoid to play whack-a-mole with every missing setting (or worse, a slightly different setting that leads to subtle change in behavior), I recommend you to delete all sdkconfig.* files from the root of the PIO project, copy over the referenced sdkconfig.defaults into your project and (since I presume you compile for the ESP32), copy the sdkconfig.defaults.esp32sdkconfig.defaults.<environment name> (e.g. esp32dev) into your project.
Yes you are right I didn’t copy the sdkconfig files (not that much into this menuconfig stuff).
So, I copied the two files ‘sdkconfig.defaults’ and ‘sdkconfig.defaults.esp32’ to my project root. I removed the old sdkconfig files and renamed ‘sdkconfig.defaults.esp32’ to ‘sdkconfig.defaults.nodemcu-32s’. But I still get the mbedtls linking errors above.
Funny thing when running the menuconfig it makes a sdkconfig file named ‘sdkconfig.nodemcu-32s’ (without the ‘default’ in the middel) as if the ‘sdkconfig.defaults.nodemcu-32s’ is ignored.
Copied the sdk file as requested and rebuild, still the same issue.
I tried to find the CONFIG_MBEDTLS_HARDWARE_MPI, CONFIG_MBEDTLS_DHM_C and the CONFIG_MBEDTLS_AES_C in the sdkconfig file but could not locate the CONFIG_MBEDTLS_DHM_C setting. The other two were as you described above.
I can see that the aes.c, where all the ‘undefined reference…’ are located, has been compiled (aes.o) and placed in the build folder of the project. So, why can’t the linker “see” these references?
Very interesting. There seems to be an actual bug in the linking logic. The aes.o file is not added to any .a archive that goes into the final linking stage.
I have this in the sdkconfig file: CONFIG_MBEDTLS_AES_C=y
and the aes.o in the project build folder (‘C:\Users\niels\Documents\PlatformIO\Projects\BlueConfig.pio\build\nodemcu-32s\mbedtls\mbedtls\library’) is 44KB, but of cause it might not be correct.
Is CONFIG_MBEDTLS_AES_C translated to MBEDTLS_AES_C before compilation?
$ nm .pio/build/esp32dev/esp-idf/mbedtls/mbedtls/library/libmbedcrypto.a | grep "mbedtls_aes"
00000000 T mbedtls_aes_self_test
$
There may be some special logic here for mbedtls to redirect it to ROM or something.
The aes.o file already doesn’t contain the file, it has U for undefined.
i$ nm .pio/build/esp32dev//mbedtls/mbedtls/library/aes.o
00000000 r aes_test_cbc_dec
00000000 r aes_test_cbc_enc
00000000 r aes_test_cfb128_ct
00000000 r aes_test_cfb128_iv
00000000 r aes_test_cfb128_key
00000000 r aes_test_cfb128_pt
00000000 r aes_test_ctr_ct
00000000 r aes_test_ctr_key
00000000 r aes_test_ctr_len
00000000 r aes_test_ctr_nonce_counter
00000000 r aes_test_ctr_pt
00000000 r aes_test_ecb_dec
00000000 r aes_test_ecb_enc
00000000 r aes_test_ofb_ct
00000000 r aes_test_ofb_iv
00000000 r aes_test_ofb_key
00000000 r aes_test_ofb_pt
00000000 r aes_test_xts_ct32
00000000 r aes_test_xts_data_unit
00000000 r aes_test_xts_key
00000000 r aes_test_xts_pt32
U esp_aes_crypt_cbc
U esp_aes_crypt_cfb128
U esp_aes_crypt_ctr
U esp_aes_crypt_ecb
U esp_aes_crypt_ofb
U esp_aes_crypt_xts
U esp_aes_free
U esp_aes_init
U esp_aes_setkey
U esp_aes_xts_free
U esp_aes_xts_init
U esp_aes_xts_setkey_dec
U esp_aes_xts_setkey_enc
00000000 T mbedtls_aes_self_test
U memcmp
U memcpy
U printf
U putchar
U put
Aha. When compiling the sources in src/, it missing the macro
-DMBEDTLS_CONFIG_FILE=\"mbedtls/esp_config.h\"
in the compile flags, that is given when everything else is compiled. That cauases blufi_security.c to use a standard config file and try to find the symbol mbedtls_aes_init, when due to the real config file applied earlier it should be looking for esp_aes_init etc. Let’s try and fix this with build_flags…
/* The following units have ESP32 hardware support,
uncommenting each _ALT macro will use the
hardware-accelerated implementation. */
#ifdef CONFIG_MBEDTLS_HARDWARE_AES
#define MBEDTLS_AES_ALT
#else
#undef MBEDTLS_AES_ALT
#endif
But how it’s mapped in is beyond me.
The CONFIG_MBEDTLS_HARDWARE_AES is defined in the sdkconfig file.
