This adds the new `nanocoap_server_observe` module that implements the
server side of the CoAP Observe option. It does require cooperation
from the resource handler to work, though.
Co-Authored-By: mguetschow <mikolai.guetschow@tu-dresden.de>
Co-authored-by: benpicco <benpicco@googlemail.com>
This allows sending a separate response with CoAP Options and adds a
helper to detect duplicate requests, so that resource handlers can
repeat their empty ACK on duplicates.
When module `nanocoap_server_separate` is not used, the functions to
send separate responses are still provided, just in a broken version:
They will send the separate replies from a different endpoint than the
request was received at (even on machines with only one IP address, as
also the source port is randomized).
This changes the behavior to only provide the functions for separate
response when the do work, so that others will detect an invalid
configuration at compile time rather than at run time.
The documentation is duly updated.
When RFC 8974 support (module `nanocoap_token_ext`) is in use, the
request token may be longer than the buffer in the separate response
context is large. This adds a check to not overflow the buffer.
Sadly, this is an API change: Preparing the separate response context
can actually fail, so we need to report this with a return value.
The example application has been adapted to only proceed if the separate
reply context could have been prepared, and rather directly emit a
reset message if the token exceeds the static buffer.
Co-authored-by: benpicco <benpicco@googlemail.com>
18620: core: add core_mutex_debug to aid debugging deadlocks r=maribu a=maribu
### Contribution description
Adding `USEMODULE += core_mutex_debug` to your `Makefile` results in
on log messages such as
[mutex] waiting for thread 1 (pc = 0x800024d)
being added whenever `mutex_lock()` blocks. This makes tracing down
deadlocks easier.
### Testing procedure
Run e.g.
```sh
USEMODULE=core_mutex_debug BOARD=nucleo-f767zi make -C tests/mutex_cancel flash test
```
which should provide output such as
```
Welcome to pyterm!
Type '/exit' to exit.
READY
s
[mutex] waiting for thread 1 (pc = 0x8000f35)
START
main(): This is RIOT! (Version: 2022.10-devel-841-g5cc02-core/mutex/debug)
Test Application for mutex_cancel / mutex_lock_cancelable
=========================================================
Test without cancellation: OK
Test early cancellation: OK
Verify no side effects on subsequent calls: [mutex] waiting for thread 1 (pc = 0x800024d)
OK
Test late cancellation: [mutex] waiting for thread 1 (pc = 0x0)
OK
TEST PASSED
```
```sh
$ arm-none-eabi-addr2line -a 0x800024d -e tests/mutex_cancel/bin/nucleo-f767zi/tests_mutex_cancel.elf
0x0800024d
/home/maribu/Repos/software/RIOT/tests/mutex_cancel/main.c:51
```
### Issues/PRs references
Depends on and includes https://github.com/RIOT-OS/RIOT/pull/18619
19296: nanocoap: allow to define CoAP resources as XFA r=maribu a=benpicco
19504: cpu/cc26xx_cc13xx: Fix bogus array-bound warning r=maribu a=maribu
### Contribution description
GCC 12 create a bogus array out of bounds warning as it assumes that because there is special handling for `uart == 0` and `uart == 1`, `uart` can indeed be `1`. There is an `assert(uart < UART_NUMOF)` above that would blow up prior to any out of bounds access.
In any case, optimizing out the special handling of `uart == 1` for when `UART_NUMOF == 1` likely improves the generated code and fixes the warning.
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:88:8: error: array subscript 1 is above array bounds of 'uart_isr_ctx_t[1]' [-Werror=array-bounds]
88 | ctx[uart].rx_cb = rx_cb;
| ~~~^~~~~~
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:52:23: note: while referencing 'ctx'
52 | static uart_isr_ctx_t ctx[UART_NUMOF];
| ^~~
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:89:8: error: array subscript 1 is above array bounds of 'uart_isr_ctx_t[1]' [-Werror=array-bounds]
89 | ctx[uart].arg = arg;
| ~~~^~~~~~
/home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:52:23: note: while referencing 'ctx'
52 | static uart_isr_ctx_t ctx[UART_NUMOF];
| ^~~
### Testing procedure
The actual change is a pretty obvious one-liner, so that code review and a green CI should be sufficient. If not, running any UART example app without regression should do.
### Issues/PRs references
None
19506: tools/openocd: Fix handling of OPENOCD_CMD_RESET_HALT r=maribu a=maribu
### Contribution description
The OPENOCD_CMD_RESET_HALT was not longer correctly passed to the script. This fixes the issue.
### Testing procedure
Flashing of e.g. the `cc2650-launchpad` with upstream OpenOCD should work again.
### Issues/PRs references
The change was added to https://github.com/RIOT-OS/RIOT/pull/19050 after testing the PR and before merging. I'm not sure if the fix never worked because of this, or if behavior of `target-export-variables` or GNU Make changed.
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
19365: bootloaders: fix bootloader button logic r=benpicco a=dylad
### Contribution description
In lastest master, the `BTN_BOOTLOADER_INVERTED` logic doesn't work as expected.
This PR fixes the underlying logic by replacing the `BTN_BOOTLOADER_INVERTED` macro definition by a runtime function.
In fact the current code:
```
#ifndef BTN_BOOTLOADER_INVERTED
#if (BTN0_MODE == GPIO_IN_PD)
#define BTN_BOOTLOADER_INVERTED false
#else
#define BTN_BOOTLOADER_INVERTED true
#endif
#endif
```
cannot work because both `BTN0_MODE` and `GPIO_IN_PD` are not known by the precompiler as they are enum values defined at cpu level.
Thus, replaces it by a runtime function in our bootloader applications.
I've also add `GPIO_OD_PU` along side `GPIO_IN_PU` and add a new define (which can be override at board level or app level) in case an external pullup is used.
### Testing procedure
Flash the riotboot_dfu bootloader:
`make BOARD=saml21-xpro -C bootloaders/riotboot_dfu flash`
Then, flash any test app:
`PROGRAMMER=dfu-util USEMODULE=usbus_dfu make BOARD=saml21-xpro -C tests/shell riotboot/flash-slot0`
With master, the application will not start.
With this PR, the application will start after flashing.
### Issues/PRs references
Fixes#19364
19366: nanocoap_sock: don't include token in empty ACK response r=benpicco a=benpicco
19367: cord: bump reference from draft to rfc r=benpicco a=bergzand
### Contribution description
The draft is an RFC, this bumps the "see also" in the docs to the rfc.
### Testing procedure
Check that the correct RFC is linked in the docs.
### Issues/PRs references
None
Co-authored-by: Dylan Laduranty <dylan.laduranty@mesotic.com>
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Koen Zandberg <koen@bergzand.net>
18773: nanocoap_sock: fix handling empty ACKs with separate response r=maribu a=benpicco
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de>
