[Top][All Lists]

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

Re: [lwip-users] TCPIP and MAC thread task priorities

From: Noam Weissman
Subject: Re: [lwip-users] TCPIP and MAC thread task priorities
Date: Mon, 27 Feb 2017 13:53:41 +0000

Dear Sylvain,

If you issue portDISABLE_INTERRUPTS() it will mask all interrupts

If you issue portENTER_CRITICAL() it will only mask interrupts that have a 
Lower than the FreeRTOS one interrupt.

See these:

In this link check the paragraph that starts with Attention please!:



-----Original Message-----
From: lwip-users [mailto:address@hidden On Behalf Of Sylvain Rochet
Sent: Monday, February 27, 2017 2:25 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] TCPIP and MAC thread task priorities


On Mon, Feb 27, 2017 at 11:50:26AM +0000, Noam Weissman wrote:
> Hi All,
> This comes from my own experience with STM micro that has Cortex-M 
> core Running with FreeRTOS. It does apply to STM9 etc...
> TCP main task priority should be high priority. It should not be the 
> highest priority but it should not be lower than other tasks that 
> consume lots of time share.
> The most misunderstood issue is interrupt priority levels in Cortext-M 
> and FreeRTOS.
> First of all: A lower number in Coretex means a higher priority while 
> in FreeRTOS a higher number Means a higher priority.
> Secondly Cortex use a nesting interrupt and a smart level... Assume 
> you set an interrupt to level 2 and try to run some critical section 
> code from RS232 but that RS232 has an interrupt level set at 5.
> What happens is that the interrupt 2 (higher) will never be masked 
> because the issuer of the Critical section runs at a lower interrupt 
> level.
> FreeRTOS has lots of sections like this one:
>   {   
>      // some code
>   }   
>   portEXIT_CRITICAL();
> If you set your interrupt level to be higher priority than the 
> FreeRTOS timer tick that part will never Be masked and your critical 
> section will not work as expected.

I don't understand any of this, portENTER_CRITICAL/portEXIT_CRITICAL
proper implementation is to disable *ALL* interrupts, therefore having a 
critical section which is not enforced for whatever reason can't happen at all.

By the way, FreeRTOS is not supposed to run with nested interrupts, you have to 
put all OS calls from interrupts (i.e. *FromISR() functions) in a critical 


reply via email to

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