[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AW: AW: [lwip-users] WG: select timeout
From: |
Mathias Zenger |
Subject: |
AW: AW: [lwip-users] WG: select timeout |
Date: |
Wed, 3 Feb 2010 15:12:43 +0100 |
Kieran: Sorry for the CC I sent to your direct address.
As discussed I contacted the ATMEL technical support and placed my question
in the AVRFreaks forum (no replies so far).
Meanwhile I was debugging my project (more and more desperate).
Unfortunately I never managed to activate the debug outputs for this port.
That's why I am kind of blind. However, I saw that the allocation of the
timeout structure in sys_timeout(u32_t msecs, sys_timeout_handler h, void
*arg) seemes to fail.
... // Breakpoint reached
timeout = memp_malloc(MEMP_SYS_TIMEOUT);
if (timeout == NULL) {
LWIP_ASSERT("sys_timeout: timeout != NULL", timeout != NULL);
return;
}
timeout->next = NULL;
... // Breakpoint never reached
There is a thread in lwIP devel
(http://old.nabble.com/Memory-leak-for-timeouts-td13602845.html#a13603364)
which talks about system threads and application threads and difficulties
regarding per-thread data. Also select() is mentioned in this context which
I am using in my FreeRTOS task. Can anybody help me to get the clue?
I haven't updated from 1.3.0 to 1.3.2 so far. Perhaps this could help but I
guess the system specific parts of the ATMEL port are not up to date.
Mathias
-----Ursprüngliche Nachricht-----
Von: Kieran Mansley [mailto:address@hidden
Gesendet: Dienstag, 2. Februar 2010 15:16
An: address@hidden
Betreff: Re: AW: [lwip-users] WG: select timeout
On Tue, 2010-02-02 at 14:08 +0100, Mathias Zenger wrote:
> I am a bit lost and would appreciate your help. Where shall I dig? :)
First I'd keep this sort of thing on the mailing list rather than by
direct mail - there are lots more knowledgeable people besides me, so
you'll stand a better chance of getting a good answer, and there might
be other people with the same question who would benefit from your
results.
It sounds like the port is using this code that should invoke a callback
after the required timeout that will signal the semaphore and wake it
from the sys_sem_wait:
...
if (timeout > 0) {
/* Create a timer and pass it the address of our flag */
sys_timeout(timeout, sswt_handler, &sswt_cb);
}
sys_sem_wait(sem);
...
After that, like you I feel a bit lost, particularly as I don't have the
port to hand to look at the code. Might be a good idea to contact ATMEL
at this point to see if they know what's wrong.
Kieran
- AW: AW: [lwip-users] WG: select timeout,
Mathias Zenger <=