[lwip-users] thanks all

[Eric Shufro]

Yeah I have debug stuff on and I can set watch points on memory locations. I
think it may be a threading problem.

The timers are being called outright like arp_tmr(), tcp_fine_tmr() etc...
from the main thread where I set the netif up and initialize and bind my
listening tcp and tcp for direct connections.

After that, there is another task for the cs8900 service routine, and
another one for sending rs232 input which is signaled from the rs232 receive
ISR.

I was not connecting to the stack externally when I get the error, and only
one thread ever calls tcpwrite.. so im not sure how it could happen
concurrently even if the mutex's are wrong, and I am sure they are.

How should I go about securing the stack mutex wise?

Do I place one around the cs8900 driver infinite while loop that pends on
the cs8900 interrupt ISR for reading stuff out of the chip?

And again try to aquire a mutex every place I call tcp_connect, or udp_send,
or even go into the arp / dhcp files and add it there too ??

Seems very intrusive to protect for the arp and dhcp stuff as well, being
that they are not user tasks.

Lastly, how does the sys.c stuff actually perform a timeout? I looked
through all of that and don't see any indirect calls to the ucos OSTimeDly()
function or anything similar. - did I miss something,

Thanks again leon / kieren. I appreciate the input.

--eric