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>
Enable the 32.768-kHz crystal on all the CC2538 platforms where it is
present in order to get a better time accuracy.
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.
This patch adds a Dockerfile for building a container configured as a
build environment for Intel Galileo boards. This patch also provides
documentation for using the containerized build environment. Finally, it
streamlines the instructions for booting Contiki on Galileo and includes
other documentation refinements.
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.
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
