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 pointing
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 point
to itself. It is easy enough to catch it pointing to itself and make that
null. I verified that this was the first pdb, that we weren't going to
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 to
spend some more time on this issue. I'm just glad to get it out there
and let others know it's happening.
__
Steve
.
On 10/14/2015 3:22 AM, Enrico Murador -
Research & Development - CET wrote:
Hi Stephen,
Maybe your workaround is not a safe way to overcome the problem: at that point the pcb chain is already corrupted (and probably unrecoverable?).
What compiler/toolchain are you using?
Enrico
On 13/10/2015 11:48, Sylvain Rochet wrote:
Hi Stephen, 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 pcb->next...I didn't have to read further. As usual, it looks like a broken port or usage which violate lwIP threading model. Summary: - Do *NOT* call anything in interrupt context, nothing, never, absolutely never, use your OS semaphore signaling to an Ethernet/serial/… RX threadI 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 modified.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. Sylvain _______________________________________________ lwip-users mailing list address@hidden https://lists.nongnu.org/mailman/listinfo/lwip-users
--
Enrico Murador
R&D
CET Electronics snc
via E. Fermi, 1
31050 Zenson di Piave (TV) Italy
Phone: +39 0421 344100
Fax: +39 0421 464042
PI/VAT IT01780330260
Web: http://www.cet-electronics.com/
_______________________________________________ lwip-users mailing list address@hidden https://lists.nongnu.org/mailman/listinfo/lwip-users
