The function _eth_arch_low_level_input() is meant to pass data into
LWIP and to prepare the ethernet buffers to receive more data.
If the LWIP heap is empty and the call to pbuf_alloc() in
_eth_arch_low_level_input returns null, the ethernet receive buffers
are not updated to receive data. Because of this the ethernet RX
interrupt will not fire. Since the RX interrupt is the only thing that
triggers a call to _eth_arch_low_level_input(), the receive buffers
will never get cleared, and the device stops receiving data.
To prevent this from happening, this patch ensures that the function
_eth_arch_low_level_input() clears the receive buffers even if a new
pbuf for the data couldn't be allocated.
This issue can be reproduce by running the test
"features-feature_lwip-tests-mbedmicro-net-udp_echo_parallel"
and on the same machine running the below python script to flood the
device with UDP broadcast packets:
MY_IP = #ADD your local IP here
from socket import *
s = socket(AF_INET, SOCK_DGRAM)
s.bind((MY_IP, 1234))
s.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1)
s.setsockopt(SOL_SOCKET, SO_BROADCAST, 1)
for _ in range(1000):
s.sendto("test data", ('255.255.255.255', 1234))
print("Message sent")
Based on lwip_ethernetif.c skeleton file,
use init, receive and transfer
functionality of SMSC9220 Ethernet driver
for the lightweight IP stack.
Receive mechanism is interrupt driven.
HW buffer sizes:
Tx = 4608 bytes (MTU)
Rx = 10560 bytes
lwIP fine tuning:
mbed-os/features/FEATURE_LWIP/lwip-interface/lwip/src/include/lwip/opt.h
Change-Id: I0ea95650c65fb32cafb5c2d3dde11420c61dba66
Signed-off-by: Gabor Kertesz <gabor.kertesz@arm.com>
The semaphore xTXDCountSem had the count to match the number of
resources available, but was being used as a binary semaphore in a
loop to listen for events. This patch updates the logic to make use of
the resource count.
With RTX5 the OS traps with an error if the a semaphore is released
more times than its count with an error similar to
"Semaphore 10000e6c error -17". Because xTXDCountSem is being used
as a binary semaphore it triggered this trap. With this patch the
semaphore is no longer used as a binary semaphore and no longer traps.
GCC have not been capable enough to catch some linker errors which arose when
ethernet support for LWIP was disabled. Checks have been added to make sure that
unrefrenced code is not linked in.
nsapi_ppp glue layer is made more transparent to public cellular API. Storage of IP
addresses is removed. PPP layer already stores the addresses, so we pass the pointer back
to the upper layers.
If PPP is not used, we provide dummy functions.
* state machine corrections
* adding various standard API methods
* Addition/revision/enhancement of the nsapi_ppp glue layer
* Turning off debug by default
Originally the ethernet ISR would be linked in to all mbed-os based
firmware because it was named ENET_IRQHandler() so that it would be
automatically placed in the FLASH image's interrupt vector table. This
meant that programs which made no use of the lwIP stack still pulled in
this ISR.
This commit changes the name of the routine so that the ISR isn't
automatically placed in the interrupt vector table at link time but is
instead dynamically placed in the interrupt vector table at runtime
when the lwIP stack is initialized. Now the ethernet ISR is only linked
in when it is actually needed.
Example arm-none-eabi-size output for a simple LED blinking program
showing the before and after size results:
text data bss dec hex filename
13208 148 7784 21140 5294 LPC1768/HelloWorld.elf
text data bss dec hex filename
12700 148 7468 20316 4f5c LPC1768/HelloWorld.elf
From opt.h:
IP_SOF_BROADCAST_RECV (requires IP_SOF_BROADCAST=1) enable the broadcast
filter on recv operations.
The IP_SOF_BROADCAST_RECV option does not enable or disable recieving
broadcast packets, it only enables a software filter.
Previously, exhausting hardware buffers would begin blocking the lwip
thread. This patch changes the emac layer to simply drop ethernet
frames, leaving recovery up to a higher level protocol.
This is consistent with the behaviour of the emac layer when unable
to allocate dynamic memory.
This was actually several bugs colluding together.
1. Confusion on the buffer-semaphore paradigm used led to misuse of the
tx semaphore and potential for odd behaviour.
2. Equality tests on tx_consume_index and tx_produce_index did not
handle overflow correctly. This would allow tx_consume_index to catch
up to tx_produce_index and trick the k64f_rx_reclaim function into
forgetting about a whole buffer of pbufs.
3. On top of all of that, the ENET_BUFFDESCRIPTOR_TX_READ_MASK was not
correctly read immediately after being set due to either a compiler
optimization or hardware delays. This caused k64f_low_level_output
to eagerly overrun existing buff-descriptors before they had been
completely sent. Adopting the counting-semaphore paradigm for 1 avoided
this concern.
As pointed out by @infinnovation, the overflow only occurs in the rare
case that the 120MHz CPU can actually generate packets faster than the
ENET hardware can transmit on a 100Mbps link.
Sam Grove
Russ Butler
Martin Kojtal
gabker01
Mika Leppänen
Tony Wu
Yuguo Zou
Hasnain Virk
Kevin Bracey
Bartek Szatkowski
0x6d61726b
Adam Green
Rob Meades
Christopher Haster
cyliangtw
adustm
Mahadevan Mahesh
andreas.larsson