|Subject:||Re: [lwip-users] lwip stall|
|Date:||Mon, 6 Oct 2014 13:17:10 +0000|
I came across your post and checked that these changes had been applied. Looking at the latest source, they have been. So this does not seem to be what is causing my problems.
What is also strange, besides the original problem ,is that I get intermittent message rates. Sometimes (from a fresh restart of the mcu) it gets a rate of say 2 a second (slow), sometimes it runs considerably faster, say 20-30 messages a second (with all debug info) for a period then drops down to the slow rate.. *scratches head* I was suspecting this may be my printf debugging to the uart, but I see this behaviour with/without printing anything.
Something else odd was that, usually when it stalls, I get the continued messages mentioned in my original post. Last night, I put a breakpoint into the tcp_input function, and stepped through it a couple of times - this seems to cause the the message queue that the recv function is blocking on to get serviced, and the socket timed out. Without dropping a breakpoint into tcp_input as soon as it stalls, the recv socket call never seems to return.. its almost like something is getting starved...
I will get back onto this later and hopefully be able to provide more information for anyone who might be able to help ...
"STM32CubeMX is part of STMicroelectronics STMCube™ original initiative to ease developers life " - stm
> Date: Mon, 6 Oct 2014 09:51:17 -0300
> From: address@hidden
> To: address@hidden
> Subject: Re: [lwip-users] lwip stall
> Thank you Jens !!!!
> I'm discussing this with my shrink, the STM bug haunts me in my
> dreams... ;^)
> Maybe Simon can modify the list signup banner to read:
> "if you are using an ST micro with the STCube software, apply this patch
> and try before you sign up and post"
> Never mind, just joking, fancy putting this along with an explanation in
> the wiki ? (No guarantee STers will read it anyway)
> lwip-users mailing list
|[Prev in Thread]||Current Thread||[Next in Thread]|