Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


lpc1768 / freertosdemo frame dupe question

Posted by Skashkash on September 24, 2010
I'm new to freertos and to these forums, so if this is not an approprate place to ask this questiom, could someone please direct me to the proper forum. Thanks.

Using freertos v6.0.5 rtosdemo_rdb1768 (cortex_lpc1768_gcc_redsuite) on an nxp lpcxpresso1768 board.
lpcxpresso compile and debug environment.

I had to modify the freertos demo code to support the lan8720 phy on the lpcxpresso board. The code changes were limited to the phy init and link status routines. Code seems to be working pretty much as expected, the web server delivers pages properly.

But I noticed some odd behaviour when pinging my device. I was getting two reply frames for every icmp request.

I see that the vSendEMACTxData function and the vEMAC_ISR seem to be set up to send each outgoing ethernet frame twice.

After the frame goes out via DMA, it's sent yet again by the ISR and then usSendLen is cleared to prevent a third transmission.

Is there a reason for this? Or is it just partial code waiting for some error handling.


RE: lpc1768 / freertosdemo frame dupe question

Posted by Richard on September 24, 2010
The biggest drawback of uIP is the fact that you can only have one packet outstanding on the network at any one time. This means
communicating with a desktop machine is very slow because the desktop will wait 200ms between receiving a packet and acknowledging the packet. This is standard practice in non real-time TCP/IP stacks to minimise network traffic - it waits to see if any more packets come so it can acknowledge more than one packet at a time.

There are ways around this and so speed up communication without having to change the configuration of your desktop TCP/IP stack, but like everything in engineering - there are trade off's to be made. Gain in one place, loose in another. I have several schemes I'm working on (code named FreeTCPIP), but one easy way of speeding up uIP is to simply send each packet twice. This tricks the other end into thinking it has missed a packet, and this causes it to send the ACK immediately. The cost of this is more bits on the wire, but if you have a decent DMA the microcontroller hardly notices.


RE: lpc1768 / freertosdemo frame dupe question

Posted by Skashkash on September 24, 2010
Thank you,
That makes perfect sense, and explains why wireshark was seeing the extra frames.
I don't know yet if the extra traffic on the wire will be an issue or not with my app. The lpc1768 seems to have the resources to handle other, more resource demanding stacks. I'll continue to research and experiment.

Again, thanks.


RE: lpc1768 / freertosdemo frame dupe question

Posted by Richard on September 24, 2010
I would be *very* grateful if you could post your LPCXpresso project to the FreeRTOS Interactive site. I think there would be a lot of interest in it. Even from me!



RE: lpc1768 / freertosdemo frame dupe question

Posted by Skashkash on September 24, 2010
I'm pretty new to this (at least ARM & FreeRTOS).

The hardware mods (adding the magnetics and RJ45 to the lpcxpresso1768) were simple. I designed a simple carrier PCB for the lpcxpresso1768. It really helps to not have to solder the CPU or the PHY chip.

Moding the example code (after FINALLY discovering that there was V1 and a V2 of the RDB1768 board schematic) to change from the DP83848 to the LAN8720 PHY was also pretty simple.

I can't easily post any of the hardware due to job conflicts. But the mods to the software are just early proof of concept tests.
The software mods can be happily shared, and I'll try to post them after a bit of clean up.

BTW, The lpcxpresso1768 is an AMAZING value for doing ARM M3 development with networking. (I just hate to keep typing that name).


RE: lpc1768 / freertosdemo frame dupe question

Posted by Artem Pisarenko on April 4, 2011
What ???!!! I've broken my brain searching the cause of double sending of packets ! It turns out that this is not a bug but a feature ! I see most use TCP only. What's about UDP? It's problem here. How to remove this "feature" ?

P.S.: I think you should make this feature optional on some #define. Document this feature at least.

[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers


STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner