19383: cord: include gcoap_req_send returning 0 in error r=benpicco a=bergzand
### Contribution description
gcoap_req_send returns 0 if it was unable to send the CoAP request. CoRD did not include that case in the return code checks. This changes CoRD to include it and drop the registration if CoAP could not send the request. The old behaviour made the CoRD thread lock up.
### Testing procedure
- Check with the gcoap API docs.
- I can reliable trigger the issue with a RIOT application including both the `cord_ep_standalone` module and some measurement reported both sending requests to the same application. If at some point the application is shut down, gcoap has all its memo's occupied with the measurement reporting and can't add the CoRD update request. Thus the CoRD update request fails with a zero code and the thread (previously) would lock up.
### Issues/PRs references
None
19385: cpu/stm32/periph/timer: fix clobered IRQ flag r=benpicco a=Enoch247
### Contribution description
From the git commit:
> The STM32 periph_timer driver reads the timer's status flags, then clears them all. It is possible that a timer interrupt could occur between reading the flag and clearing it. This would lead to a lost interrupt.
>
> The timer's status flags can be cleared by software, but can only be set by the hardware. This patch takes advantage of this by only clearing the flags it knows are set. The rest of the flags are set, which doesn't actually change their state.
I had trouble finding anything in ST's datasheet saying that software could not set the timer's status flags, but testing showed that this is how it works in practice. Further, [ST's own HAL ](https://github.com/STMicroelectronics/STM32CubeF4/blob/master/Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal_tim.h#L1258)confirms this. If the hardware didn't work this way, it would be impossible to atomically read-modify-write the flags.
### Testing procedure
I tested by doing the following:
1. `make -C tests/periph_timer BOARD=nucleo-f767zi all flash term`
2. press s
3. press [ENTER]
4. observe test passes
5. `make -C tests/periph_timer_periodic BOARD=nucleo-f767zi all flash term`
6. press s
7. press [ENTER]
8. observe test passes
9. `make -C tests/periph_timer_short_relative_set BOARD=nucleo-f767zi all flash term`
10. press s
11. press [ENTER]
12. observe test passes
### Issues/PRs references
- none known
Co-authored-by: Koen Zandberg <koen@bergzand.net>
Co-authored-by: Joshua DeWeese <jdeweese@primecontrols.com>
gcoap_req_send returns 0 if it was unable to send the CoAP request. CoRD
did not include that case in the return code checks. This changes CoRD
to include it and drop the registration if CoAP could not send the
request. The old behaviour made the CoRD thread lock up.
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>
This is an API change in the latter, which would typically now take an
extra argument GCOAP_SOCKET_TYPE_UNDEF.
Follow-Up-For: https://github.com/RIOT-OS/RIOT/pull/16688
19142: sock_dtls: move common code into sock_dtls_establish_session() r=benpicco a=benpicco
Co-authored-by: Benjamin Valentin <benpicco@beuth-hochschule.de>
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>
If a NON confirmable message is sent with a callback function,
not receiving a response in time would lead to a retransmission.
This is of course an error, as only CON messages are to be retransmitted.