The commit will address the test failure of connectivity-netsocket-tests-tests-network-interface.
In the test, serial channel will break with the sequence: ESP8266Interface::connect() > disconnect() > connect()
In the first connect, both board's and ESP8266's serial flow control default to disabled, and then enabled.
In the second connect, board's serial flow control keeps enabled but ESP8266's resets to disabled, causing inconsistency between two ends.
The approach: Explicitly disable board's serial flow control on re-power or reset in (re-)connect
On interop test 1.2.2.4, Join Request retransmission is expected to be 6
s + worst case air transmission. This delay is to accommodate for
JoinAccept through RX2.
The `call_in` in process_reception_timeout of RX2-window adds 500 ms
delay between RX2 symbol-interrupt-timeout and the next join request
retransmission. This is an isolated change and only affect the
retransmission of Join Request.
Adding this delay improves the chance of succeeding test
1.2.2.4 (subset of 1.2.2)
Fixed issue on LoRaWANStack based on lorawan v1.0.2 specification page
24 line 25-27. The specification mentioned that that end-device shall
stop retransmission when receiving ANY downlink on RX1 or RX2 window.
- Removed conflicting behavior in
LoRaWANStack::post_process_tx_with_reception()
- Updated comment section of nb_trials at lorawan_data_structures.h
A bug was detected when the uint8_t SUBGRF_GetFskBandwidthRegValue( uint32_t bandwidth )
is called and the bandwith argument has a value of 0.
Comparing the code to the STMCubeWL 1.1 we can see that an if statement is missing to
address the condition where bandwith is equal to 0.
Added the if statement to the radio driver to account for this edge case.
To actually get the filename in the error reporting struct instead of
the start of the path, let's use the MBED_FILENAME macro that MBED_ERROR
et al uses.
Use uint16_t variables for i2c slave_rx_buffer_size and slave_rx_count
variables. This allows to receive more than 255 bytes in slave mode. The
bytes are received one by one in slave mode so there are no hardware
limitations forcing a 1 byte rx count limit.
The HAL gpio_irq_api stores object IDs, which serve as a form of context
for the dispatch of the interrupt handler in the drivers level
InterruptIn Class. The way this is achieved is that the InterruptIn
Class casts its address to uint32_t, which is stored as the ID.
This results in compilation failure when the size of an object pointer
is greater than uint32_t, for example when building on a PC for unit
testing.
In order to allow Unit Testing of the InterruptIn Class, we replace the
use of uint32_t with uintptr_t (type capable of holding a pointer),
which allows portability and expresses intentions more clearly.
In aid of this latter goal, we also replace the use of the name "id"
with "context", to improve clarity - these are addresses of the context
related to that callback.
Martin Kojtal
Chun-Chieh Li
Pavel S
Deepak V. Shreshti
Anthony Mcnicoll
Jerome Coutant
zul
Zulkarnaen
LukaB
Henrik Persson
Mathieu Othacehe
Ladislas de Toldi
wally0258
Hari Limaye