Previously, the test vectors were encoded into the python test scripts,
converted to base64, and send over to the device under test via stdio.
The application sent back the output after converting it to base64
first, which was read back in by the test script and decoded. Finally,
the test script compared the result with the expected result.
This made the test complex, slow and, flanky, as stdio on interfaces
such as UART has a high bit error rate and some quirks (e.g. the EDBG
UART bridge e.g. in the samr21-xpro dropping bytes when bursts of more
than 64 bytes at a time are send).
This basically rewrites the test to embed the test vectors in the
firmware and do the comparison on the devices. This fixes test failures
on the samr21-xpro, the nRF52840-DK and likely many others. Also, it
is now fast.
Having to cast a password provided as `const char *` to
`const uint8_t *` is a needless pain in the ass when using the API.
Hence, fix it by accepting passwords and salts as `const void *`
instead.
These models have 256 kByte RAM, but the upper 64 kByte are used as CCM data RAM accessible at 0x1000:0000. The access to 0x2003:xxxx leads to a hard fault.
Since fmt no longer has a significant advantage in stack consumption,
we need to bump the `MIN_SIZE` guard that prevents causing stack
overflows due to the printing of the stack consumption.
Hooking into the existing wrappers for `malloc()`, `calloc()`,
`realloc()`, and `free()`, the new (pseudo) module `malloc_tracing`
prints out the calls to the given functions, the program counter of
the caller, as well as the return result.
The intent is to aid debugging double-frees, invalid frees, or memory
leaks.
The commit 98478e02fe removed the setting of the CFG_TUD_MAX_SPEED define to OPT_MODE_DEFAULT_SPEED. This setting is usually not required since CFG_TUD_MAX_SPEED is determined from CFG_TUSB_RHPORT{0,1}_MODE. However, this does not work for STM32F429I-DISC1 where the HS port is used via the internal FS-PHY. Therefore the default speed setting is added again.
With PR #18835, the automatic generation of descriptors for the most common device classes and their handling was introduced. The update of the documentation was forgotten.
It turns out that the fix for the missing terminating newline is not
robust. This hopefully fixes the issue and resolves the following
error message:
In file included from /home/maribu/Repos/software/RIOT/tests/pkg_emlearn/main.c:25:
/home/maribu/Repos/software/RIOT/tests/pkg_emlearn/model.h:7221:36: error: stray '\' in program
7221 | /* fix for no newline at eof */\n
| ^
/home/maribu/Repos/software/RIOT/tests/pkg_emlearn/model.h:7221:38: error: expected ';' before '_Alignas'
7221 | /* fix for no newline at eof */\n
| ^
| ;
Modern binutils complain about segments with RWX permissions. While
this is indeed a bad habit, RIOT ignores segments permissions anyway.
(We do have a `mpu_noexec_ram` module to disable execution of all of
RAM, which would do so regardless of the segment permission.) So for
now, we can safely just disable the warning.
This fixes:
/usr/lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld: warning: /home/maribu/Repos/software/RIOT/examples/default/bin/nucleo-f767zi/default.elf has a LOAD segment with RWX permissions
collect2: error: ld returned 1 exit status
