Hi Artem, You bring up an interesting point. It's true that the netconn api utilizes stack-allocated variables so if that memory is protected there would be a violation.
Question: is it important for your application thread and the tcpip thread to be in different protected memory regions? is it possible for that memory to be accessed by both threads? Cheers Ivan > Date: Wed, 29 Aug 2012 09:50:53 +0700 > From: jblackarty <[email protected]> > To: Mailing list for lwIP users <[email protected]> > Subject: [lwip-users] lwip and MPU (FreeRTOS-MPU) > Message-ID: <[email protected]> > Content-Type: text/plain; charset=windows-1251 > > Hi all, > > I've ported lwip to FreeRTOS-MPU (ARM Cortex-M3, GCC) and suddenly > found that lwip design violates FreeRTOS memory access > restrictions. The problem is that lwip tcpip thread accesses local > variable allocated on stack of application thread which uses Netconn > API. FreeRTOS-MPU protects thread stacks because stack corruption > (made by other threads) can corrupt freertos kernel data and thus > cause crash of whole system > LwIP is most unreliable (because most complex) component in my > system. Therefore, it's first candidate to have most rectricted access > rights in my system. Ironically, it happened that I'm forced to give > it access to application thread stacks and thus make it the only > component which may cause whole system crash ! And seems like it does > it already in my tests, but I'm not sure so far because I didn't found > that it's lwip who does it (it's only a week passed since I started > debbugging which driving me crazy). > I have absolutely no idea how to solve it keeping lwip code > unmodified. What do you think about it ? > > Regards, > Artem Pisarenko > _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
