The functions smsc9220_receive_by_chunks and smsc9220_send_by_chunks are
supposed to implement receiving and sending packets by chunks. However,
the functions SMSC9220_EMAC::low_level_input and SMSC9220_EMAC::link_out,
which call them respectively, already require or assemble the full packet.
Also, smsc9220_receive_by_chunks doesn't implement the "chunks" part.
This commit renames the functions to smsc9220_receive_packet and
smsc9220_send_packet. The functions now do their operations by word
instead of by bytes. The functions SMSC9220_EMAC::low_level_input and
SMSC9220_EMAC::link_out already handle allocation, continuity and word
alignment of the packet buffer.
The function SMSC9220_EMAC::low_level_input should create a heap for the
packet equal to the size of the message (most of which are couple hundred
bytes). The current code uses maximum frame size (1522 bytes) for each
packet. This will cause the heap to quickly fill up. In fact, the default
memory size (lwip.mem-size) used for this heap is 1600 bytes. This means
that once you have one other packet allocated (extremely common), the
heap allocation will always fails.
Also, it is recommend to increase the default lwip.mem-size because that
amount is very small especially if you send or receive a few large packets
in the network. This is NOT done in current commit.
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
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.
This commit enables the Overriding of HAL callbacks and IRQHandler
in stm32xx_emac.cpp. Hence the user can have their own
implementations of callbacks and IRQHandler functions.
Signed-off-by: Kather Rafi Ibrahim <katherrafi.i@hcl.com>
Current BT_POWER sequence:
1. BT_POWER=0 ( from CyH4TransportDriver::initialize)
2. delay 1ms ( from CyH4TransportDriver::initialize)
3. BT_POWER=1 ( from CyH4TransportDriver::initialize)
4. delay 500ms (from HCIDriver::do_initialize)
5. BT_POWER=1 (from HCIDriver::do_initialize)
6. delay 500ms (from HCIDriver::do_initialize)
updates:
1. remove 4) and 5)
2. keep all BT_POWER operations in one place. The best logic place is CyH4TransportDriver::initialize.
So finally the BT_POWER sequences should looks like:
1. BT_POWER=0 ( from CyH4TransportDriver::initialize)
2. delay 1ms ( from CyH4TransportDriver::initialize)
3. BT_POWER=1 ( from CyH4TransportDriver::initialize)
4. delay 500ms ( from CyH4TransportDriver::initialize)
Now, CYW43XXX Cordio HCI driver has the following MCU deep-sleep locking scenarios/flows:
a) A BT device or MCU does not support Low Power mode (MBED configuration does not include MBED_TICKLESS, DEVICE_SLEEP, DEVICE_LPTICKER or CYCFG_BT_LP_ENABLED features). In this case, CyH4TransportDriver locks deep-sleep in the initialize() function and unlocks the terminate() function.
b) A BT device and MCU support Low Power mode. In this case, the control of the unlock/lock of the deep-sleep functionality will be done in bt_host_wake_rise_irq_handler and bt_host_wake_fall_irq_handler handlers. Finally, CyH4TransportDriver unlocks the deep-sleep in terminate() function (if it was locked before) by checking the bt_host_wake_active flag.
Fixes#13076, #13700, #13295.