Hi Kieran, On 21/11/2011 19:40, Kieran Mansley wrote: > > On 20 Nov 2011, at 22:06, Richard Barry wrote: > >> Does this make any sort of sense? > > Not really. I can't see how a bug in that code would cause the > symptoms you describe. My guess is that the optimisation is causing > a change in timing that leads to some race condition being exposed. > E.g. if it is running faster there is more chance of packets backing > up, resulting in a queue that then becomes corrupted. When it was > running slower the packets never backed up and so there was no queue, > and no chance for corruption. Unfortunately this means that the file > being optimised may not have the bug that you're seeing.
I agree it seems unlikely to be something in that file. The file, from my inspection, is just a stand along C file will a few functions. No static data, no volatile data. However, I don't think your suggestion that it might be a speed of execution issue that is highlighting, rather than causing, an error is likely either. My rationale being that, I can have optimisation in *all* files set to -O0 (an there are a lot of files in the project) except inet_chksum.c, which has -O1, and the problem occurs. Therefore the application and stack are going to be running at near identical speed to when everything has -O0. It is only optimisation on that file that seems to be causing (probably highlighting, rather than causing) a problem. The inverse is also true, optimising *all* files to the max, and having inet_chksum.c without optimisation does not show the problem, and then everything really will be running much faster. Does the fact that the problem only seems to occur when the data being transmitted exceeds a single Ethernet frame give any clues as to where else there could be a problem? I can try stepping through inet_chksum to see if I can see if an issue arises, but stepping optimised code, even when optimisation is low, is a bit tricky. Regards, Richard. + http://www.FreeRTOS.org Designed for Microcontrollers. More than 7000 downloads per month. _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
