lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] lwip and MPU (FreeRTOS-MPU)


From: Ivan Delamer
Subject: Re: [lwip-users] lwip and MPU (FreeRTOS-MPU)
Date: Wed, 29 Aug 2012 09:42:39 -0600 (MDT)
User-agent: SquirrelMail/1.4.9a

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 <address@hidden>
> To: Mailing list for lwIP users <address@hidden>
> Subject: [lwip-users] lwip and MPU (FreeRTOS-MPU)
> Message-ID: <address@hidden>
> 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
>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]