This patch changes the way data is put in the TX_DATA_PORT register when
sending packet over Ethernet.
When this driver is compiled with release compilation profile
(space optimization compiler options) with Arm compiler version 5,
the line:
SMSC9220->TX_DATA_PORT = *pktptr;
generates the assembly instruction to get the pktptr pointed value:
LDM r2!, {r3}
with pktptr = r2
However, the code does not prevent the pktptr value from being unaligned
(to a 32 bits boundary) in that zone and the LDM instruction causes a
HardFault if this is the case. When the compiler option is not activated
(debug and develop compilation profiles), the compiler generates LDR
instruction instead which does not cause a HardFault.
The ARM v7-M states page B3-601: "Unaligned load-store multiples and
word or halfword exclusive accesses always fault."
To face that problem, we check if the data pointer is aligned or not. If
it is, we apply the same algorithm than before. If not, a local variable
is created and we copy in it, byte per byte, the contents at the
unaligned pointer. However, it will impact performances adding 8
instructions (one LD and one ST for each copied byte).
Change-Id: I11f6e82ce5521960d2ecf499f718f76fec29c0b0
Signed-off-by: Hugues de Valon <hugues.devalon@arm.com>
This patch fixes a memory bug. `eth_arch_enetif_init` method call
would attempt to write to un-initialized area of memory.
Change-Id: I9881de71d58fa14db609fe3e24617a210b896471
Signed-off-by: Galanakis, Minos <minos.galanakis@arm.com>
I added the function declarations of Ethernet functions that have a WEAK attribute. Although several Ethernet functions was called in rza1_emac.c, GR-LYCHEE don't have Ethernert feature. But there may be case that GR-LYCHEE uses LWIP feature.
In this case, since GR-LYCHEE will occur the build error, I addressed the error by defining the functions with a WEAK attribute. For reason of WEAK attribute, there is no influence in GR-PEACH and VK_RZ_A1H that have Ethernet feature.
I modified the debug message when using LWIP in RZ/A1 related mbed boards.
In eth_arch_enetif_init(), sys_thread_new() was called and task name is appeared as debug information, but task name for debug was a mistake.
For LWIP communication speedup in RZ_A1 related, I changed the below macro value and added the definition processing in RZ/A1 related header file(lwipopts_conf.h). For this reason, those macros are overrode by RZ/A1 related values, not default values.
In the below "features/FEATURE_LWIP" folders, same as Cortex-M targets, I changed the folder structure to combine files that can be shared as RZ/A1 related. And I renamed the folder name to "TARGET_RZ_A1XX" in order to make commonality explicit.
- "features/FEATURE_LWIP" folder
<before>
\features\FEATURE_LWIP\lwip-interface\lwip-eth\arch\TARGET_RZ_A1H
\features\FEATURE_LWIP\lwip-interface\lwip-eth\arch\TARGET_VK_RZ_A1H
<after>
\features\FEATURE_LWIP\lwip-interface\lwip-eth\arch\TARGET_RZ_A1XX
The K64F Ethernet driver installs an interrupt handler that sets thread
flags, and this could be called before the thread was initialised, so it
would use a NULL thread ID.
This triggers an RTX error-checking trap in debug builds, and could also
lead to other problems with received packets not being processed.
Adjusted so the RX interrupt handler does nothing if the thread isn't
initialised yet, and manually trigger a RX event flag after initialising
the thread in case any interrupts were ignored.
An alternative would have been to implement eth_arch_enable_interrupts,
but this mechanism is not present in the EMAC world - drivers will have
to start returning interrupts in their power up.
Fixes#5680
Target of LPC1769 links to mbed LPC1768.
The PinNames.h has conditional compile for the pin names.
LWIP lpc17xx emac driver modified to allow LPC1769 target
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.