xxwares ship these headers now, so we will switch to using those versions. The exceptions are IEEE API headers, which are for not part of xxwares, so we have to keep them locally for now.
Previously, only constants could be used to pass SPI instances to the
SPI driver. This change makes it possible to use SPI instances from
variables.
Signed-off-by: Benoît Thébaudeau <benoit@wsystem.com>
This includes support for preemption ready to be integrated into
exception handlers.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
Some arguments passed to the functions disabled with
LPM_CONF_ENABLE == 0 could trigger build warnings because they became
unused with this configuration option. Disable these functions by using
empty static inline functions instead of empty macros, so that the
function arguments are always considered by the compiler as used,
without having to #if-out code in many places.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
The log function writes directly to the screen. Combined with the usage of PFS this means that the POSIX layer of the C library isn't referenced anymore thus reducing the memory requirements.
This patch fixes the section alignment specification in the linker script for
the Intel Quark X1000 SoC so that the UEFI GenFw program generates correct EFI
binaries. See the added comment in quarkX1000.ld for details.
lpm_enter() must not enter PM1+ if the UART is transmitting. Otherwise,
the UART clock gets disabled, and its TX is broken.
The commit b8b54a033c had already
partially fixed this issue, but it could still occur while transmitting
stop bits because, contrary to UART_FR.BUSY, UART_FR.TXFE takes only the
data bits into account, not the stop bits.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
This patch fixes UART system call authorization initialization (when
protection domain support is enabled) to only initialize the system call
entrypoint and authorization data structures once, prior to per-port
setup. Previously, if two UARTs were configured, the setup procedure for
the second UART would erase the system call authorization for the
first (console) UART, resulting in a crash upon the next attempt to
perform console output.
If `NETSTACK_CONF_RADIO.set_value(RADIO_PARAM_CHANNEL, ...)` is called when radio is on, it will fail to apply the channel change, because it won't re-send `CMD_PROP_RADIO_DIV_SETUP` and `CMD_PROP_FS`. This commit fixes this condition, by making sure the correct commands are sent to the radio.
This commit changes the logic of `get_cca_info()` in the CC26xx IEEE mode driver. We now use the command's return status bits to determine whether the radio's CCA monitoring function has concluded, instead of drawing conclusions based on RSSI readings.
As discussed in #1341, the current CC13xx/CC26xx IEEE mode driver sends `CMD_GET_RSSI` once and returns the RSSI reading uncondtionally. This happens within the `get_rssi()` function.
This logic is broken if `get_rssi()` is called with the radio off. The function will make sure to turn on the radio first, but it does not make sure the RSSI reading is valid, which only happens a number of symbol periods after the radio enters RX. The outcome is that `NETSTACK_RADIO.get_value(RADIO_PARAM_RSSI, ...)` will always return -128 (meaning that RSSI is unavailable) if the radio was off at the time of calling the function.
The same condition affects the prop mode driver.
This commit changes the logic of `get_rssi()`:
* For PROP mode, if `CMD_GET_RSSI` returns an invalid RSSI, we send it again. For unknown reasons, `CMD_GET_RSSI` on occasion returns 0, so we ignore that value too.
* For IEEE mode, we use `CMD_IEEE_CCA_REQ` and we inspect the value of `ccaInfo.ccaEnergy` of the return structure. If the value is 0x02 (Invalid), we send the command again.
Fixes#1341
After reading a frame, `read()` checks the status of the RX FIFO:
* If an overflow is detected, the FIFO gets flushed
* If there are more frames in the FIFO, the `cc2538_rf_process` will get polled again in order to read out the next frame.
#1550 changed `read()`, which now performs the above check for non-poll mode, but it then flushes the FIFO unconditionally. Therefore, if there are two or more frames in the FIFO, they will get flushed before the `cc2538_rf_process` has had a chance to read them out. This results in missed frames.
Reproducing this is trivial: Build a CC2538 sniffer and see how it will never show you .15.4 ACK frames. ACK reception completes while `read()` is still streaming the previous captured frame to the host. Upon completion, the FIFO will get flushed and the ACK will get lost.
This pull proposes removing the unconditional flush and reverting to the original logic for non-TSCH operation.
Pinging @thomas-ha here for input regarding poll mode.
This pull sits on top of #1778
Depending on the use case and on the timings,
aes_auth_crypt_check_status() sometimes never reported an available
result, leading to a deadlock of any protothread waiting for this event,
and to a WDT reset if a protothread was polling it.
This was caused by aes_auth_crypt_start() clearing the result available
interrupt after operations that may rightfully trigger it, leading to a
missed interrupt.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
