I'm using GNU toolchain/compiler, supplied with Atmel Studio 6.1.
Since I've added the code I've had no other problems; I really don't
have much time to research this, what with other pressures at work.
It seems the issue is not unknown... sometimes the pdb ends up
to itself. These times appear to be correlated to high-stress I/O.
Obviously the last pdb should point to null... and it should never
to itself. It is easy enough to catch it pointing to itself and
null. I verified that this was the first pdb, that we weren't going
have a memory leak when we just terminated the list. I did not have
the resources to chase down when the pointer to self happened...
I only know that it does, and that the pdb that this happens to is
at the first allocated pdb address. The obvious thing to do was to
correct the pointer to break the endless loop... seems to work.
As Sylvain wrote, the Atmel port has some serious differences from
what he's used to seeing... I'm assuming this has something to do
with it. As I get more time (the product ships soon) I'll be able
spend some more time on this issue. I'm just glad to get it out
and let others know it's happening.
On 10/14/2015 3:22 AM, Enrico Murador -
Research & Development - CET wrote:
Maybe your workaround is not a safe way to overcome the problem:
at that point the pcb chain is already corrupted (and probably
What compiler/toolchain are you using?
On 13/10/2015 11:48, Sylvain Rochet
On Tue, Oct 13, 2015 at 10:15:42AM +0200, Sylvain Rochet wrote:
On Mon, Oct 12, 2015 at 04:59:19PM -0500, Stephen Cowell wrote:
On 10/12/2015 3:41 PM, Sylvain Rochet wrote:
On Mon, Oct 12, 2015 at 02:51:14PM -0500, Stephen Cowell wrote:
I find that I sometimes get an infinite loop when stepping to
I didn't have to read further. As usual, it looks like a broken port or
usage which violate lwIP threading model.
- Do *NOT* call anything in interrupt context, nothing, never,
absolutely never, use your OS semaphore signaling to an
Ethernet/serial/… RX thread
I don't think I'm doing that, Sylvain... this is non-OS, so there
are no 'threads'. Atmel wrote the port. I'm running sntp and ftpd, they
hook in using their own _init() routines that have not been
But there are probably interrupts, which is even worse. Could you first
check that no lwIP functions are called in interrupts contexts ?
Probably around the macb driver.
If I have time I will fetch the Atmel port for SAM4E/bare-metal and
take a short look at it.
It looks sane from a quick look. I don't really understand why there are
not using sys_check_timeouts() and rewrote everything in the ethernet.c
"static timers_info_t gs_timers_table" stuff. Since you are having
issue in timers context could you check this part is ok ? Removing all
the Atmel timers stuff and calling sys_check_timeouts() in the main loop
could be an easy check.
lwip-users mailing list
||CET Electronics snc
via E. Fermi, 1
31050 Zenson di Piave (TV) Italy
Phone: +39 0421 344100
Fax: +39 0421 464042
lwip-users mailing list