Hello,
what about to set priority of the receive packet task lower than the
tcp/ip task? After returning from an ISR, the tcp/ip task will queue
the ARP and then, when tcp/ip task is blocked while waitining for a
message, the received packet is processed.
Martin
P.S.
I am not strong at future after future grammar :)
On Mon, Feb 25, 2013 at 5:11 PM, Dave Harper <address@hidden> wrote:
> I am running lwIP along with FreeRTOS on an embedded microcontroller that
> does periodic checks to a GPS based timeserver located in the same room.
> Thus the timeserver is able to quickly respond to an ARP request
> (measurements show a consistant range of 740us to 750us). The first
> timeserver check is performed as the system starts up so this causes an ARP
> request to be sent. In the etharp_query() function, this situation is
> detected, an ARP request is sent and the IP packet is queued for later
> transmission. Unfortunately, sending the ARP request first and THEN
> queueing the IP packet seems to open up a potential timing problem. What
> I'm seeing is that occasionally between the time the the ARP request is sent
> and the time the IP packet is actually queued, there is an interruption of
> execution in etharp_query. Before etharp_query() gets to execute again, the
> timserver is able to respond with the ARP reply and this triggers input
> processing. As part of the input processing update_arp_entry() is called
> which is where queued packets are sent. Unfortunately, it finds nothing
> queued at this point so it simply returns. Eventually etharp_query()
> resumes execution and queues the IP packet but at this point it is too late.
>
> One of my debugging tools is a logic analyzer I use to trace the path of
> execution. This is done by embedding a macro that writes a unique value to
> an I/O port where it is then captured by the logic analyzer. What I found
> was the more macros I embedded to try and trace down the source of the
> problem, the worse it became (I was effectively delaying code execution and
> giving the timeserver more time to respond). By the time I finally figured
> out what was happening my SNTP request was succeeding only about 10% of the
> time.
>
> I decided to try reversing the order of operations in etharp_query - queue
> the IP packet first and then send the ARP request. What I found was that
> the SNTP request succeeded every time. Unfortunately I don't have enough of
> a grasp of full lwIP operation to know if I've only appeared to fix a
> problem but in reality simply opened up other areas for failure. I am
> running an older version of lwIP (1.3) but I checked the latest 1.41 release
> and etharp_query() operates essentially the same.
>
> Can anyone please weigh in on this?
>
> Thanks,
> Dave Harper