Related to my PR #20668, I noticed that the board was not always flashed correctly and didn't seem to respond most of the time. For your information all the tests were done using the default example. Usually on this example you should see RIOT outputs and be able to type your commands however the boards seemed locked in a state where it was not printing anything and where it was not responding to the commands typed (so basically it was not initialized or flashed correctly).
As the code in my PR, for the arduino nano 33 BLE sense, was based on the already existing code of the arduino nano 33 BLE, I tried to look for extra common configuration somewhere else than in the board directory and found out that there was only some tests that were defining the board as one that provides a net interface. I saw, using the dependency-debug target, that the dependencies were not the same and that the original arduino nano 33 BLE had more dependencies than the board I added when it should have been the opposite.
I added my new board in the following files (that seemed to be the only locations where there was an actual usage of the arduino-nano-33-ble) :
[x] tests/Makefile.boards.netif
[x] tests/drivers/mrf24j40/Makefile
[x] tests/net/ieee802154_hal/Makefile
[x] tests/net/ieee802154_submac/Makefile
[x] tests/pkg/openwsn/Makefile
[x] tests/pkg/openwsn_sock_udp/Makefile
Here you can find a zip containing the output of the command with and without the board included in the mentioned files : debug_dependencies-output-files.zip
For your information, this issue is not specifically related to my new board as some tests were made using the old one and the native board which also depends on the tests directory.
I don't think that it is normal that the compilation step needs some elements in the tests directory as they should not be related.
Description
Related to my PR #20668, I noticed that the board was not always flashed correctly and didn't seem to respond most of the time. For your information all the tests were done using the default example. Usually on this example you should see RIOT outputs and be able to type your commands however the boards seemed locked in a state where it was not printing anything and where it was not responding to the commands typed (so basically it was not initialized or flashed correctly).
As the code in my PR, for the arduino nano 33 BLE sense, was based on the already existing code of the arduino nano 33 BLE, I tried to look for extra common configuration somewhere else than in the board directory and found out that there was only some tests that were defining the board as one that provides a net interface. I saw, using the
dependency-debug
target, that the dependencies were not the same and that the original arduino nano 33 BLE had more dependencies than the board I added when it should have been the opposite.I added my new board in the following files (that seemed to be the only locations where there was an actual usage of the arduino-nano-33-ble) :
Here you can find a zip containing the output of the command with and without the board included in the mentioned files :
debug_dependencies-output-files.zip
For your information, this issue is not specifically related to my new board as some tests were made using the old one and the native board which also depends on the tests directory.
I don't think that it is normal that the compilation step needs some elements in the tests directory as they should not be related.
Versions
Operating System Environment
Installed compiler toolchains
riscv64-unknown-elf-gcc: missing riscv32-esp-elf-gcc: missing xtensa-esp32-elf-gcc: missing xtensa-esp32s2-elf-gcc: missing xtensa-esp32s3-elf-gcc: missing xtensa-esp8266-elf-gcc: missing clang: Ubuntu clang version 14.0.0-1ubuntu1.1
Installed compiler libs
riscv64-unknown-elf-newlib: missing riscv32-esp-elf-newlib: missing xtensa-esp32-elf-newlib: missing xtensa-esp32s2-elf-newlib: missing xtensa-esp32s3-elf-newlib: missing xtensa-esp8266-elf-newlib: missing avr-libc: missing (missing)
Installed development tools