NominalPrescaler value needs to be as high as possible to ensure a good approximation of the target CAN speed.
Previous usage of macro IS_FDCAN_DATA_TSEG1 refers to (unsupported by Mbed ) FDCAN CAN controller settings and leads to too low prescaler values.
Usage Macro IS_FDCAN_NOMINAL_TSEG1 yields optimum results.
See also correct macro usage in line #158.
Fix an issue where CellularContext::do_connect_with_retry() does not call NSAPI_STATUS_GLOBAL_UP callback and validate_ip_address() on successful connect after failed try in blocking mode.
Fix an issue where CellularContext::do_connect_with_retry() does not call NSAPI_STATUS_GLOBAL_UP callback on successful connect after failed try in blocking mode.
Trying to inherit the STM32F412xE target makes the linker fail, since
__CRASH_DATA_RAM_START__ is not present. Comparing LD scripts with the
STM32F412xG (which has active targets) it seems that the xE variant has
missed some updates somewhere. Since the LD scripts are otherwise
identical, copying the (working) ones from STM32F412xG seems to do the
trick.
Also added flash_data.h which was missing and needed here and there
(copied from xG and updated to fit the xE flash layout).
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_receive_by_chunks loads data from the Ethernet port.
It is expected to return the Ethernet frame without the 4 CRC bytes.
However, it is required to call the Ethernet data port register (32-bit)
an amount equal to the number of frame words (including the 4 CRC bytes)
to pop all frame words. The current code doesn't call the register for the
last word (which has CRC data). This causes subsequent calls to have this
missed word at the beginning. The impact of this is huge as the high level
API is getting fed wrong data. The fix adds one additional call to the data
port register.
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.
Deepak V. Shreshti
Michał Majcherski
Jerome Coutant
Danny Goossen
Martin Kojtal
Charles
chdelfs
Chun-Chieh Li
Saeed Kazemi
Andreas Reichle
yutotnh
Henrik Persson
byq77
mbedmain
xiaohuizhang98
Jason Reiss
Pavel S
Rami Elkhatib
tobi15
YahyaTawil