cancel
Showing results for 
Search instead for 
Did you mean: 

[BUG] FreeRTOS/LwIP thread priority range for TCPIP_THREAD_PRIO, DEFAULT_THREAD_PRIO and SLIPIF_THREAD_PRIO in CubeMX wrong

SStor
Senior

Hello,

I think the correct range for TCPIP_THREAD_PRIO, DEFAULT_THREAD_PRIO, SLIPIF_THREAD_PRIO and possible others in CubeMX LWIP configuration should be -3 to +3 and not 0 to 6.

And the default value should be lower than 3 (osPriorityRealtime) definitely to avoid conflicts with low level ETH send/receive threads.

1 REPLY 1
SStor
Senior

Ok, the issue seems to been fixed since new CubeMX 5.5.0, at least for TCPIP_THREAD_PRIO in generated file lwipopts.h

/*----- Value in opt.h for TCPIP_THREAD_PRIO: 1 -----*/
#define TCPIP_THREAD_PRIO osPriorityNormal
 
/*----- Value in opt.h for SLIPIF_THREAD_PRIO: 1 -----*/
#define SLIPIF_THREAD_PRIO 3
 
/*----- Value in opt.h for DEFAULT_THREAD_PRIO: 1 -----*/
#define DEFAULT_THREAD_PRIO 3

Now a value of 3 in CubeMX is interpreted as osPriorityNormal (0) correctly 

typedef enum {
 osPriorityIdle         = -3,         ///< priority: idle (lowest)
 osPriorityLow          = -2,         ///< priority: low
 osPriorityBelowNormal  = -1,         ///< priority: below normal
 osPriorityNormal       = 0,         ///< priority: normal (default)
 osPriorityAboveNormal  = +1,         ///< priority: above normal
 osPriorityHigh         = +2,         ///< priority: high
 osPriorityRealtime     = +3,         ///< priority: realtime (highest)
 osPriorityError        = 0x84       ///< system cannot determine priority or thread has illegal priority
} osPriority;

Could you check if the same issue also matches the interpretation for SLIPIF_THREAD_PRIO and DEFAULT_THREAD_PRIO? 

Thank you for your efforts!