EnterTaskCritical blocking higher priority interrupts

dwsexton wrote on Saturday, June 09, 2018:

CPU: STM32F407, FreeRTOS V9.0.0, IDE: Eclipse
Software came from CUBEMX
I have a real time interrupt running outside of FreeRtos, it uses no system calls. It should run at a 1msec rate.
I am using LWIP and when it makes a call to taskEnterCritical() my interrupt stops firing.
I have set the priority of the interrupt to 0 (Highest).
The configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY is set to 5 in FreeRTOSconfig.h
So I would think that when the critical section is entered that all interrupts with a priority setting >=5 would be disabled but that my real time interrupt would be allowed to run.
In tracing this down this is definately the spot where the interrupt stops getting serviced and what is worse is that since the EnterTaskCritical is nesting my interrupt does not get serviced until the last ExitTaskCritical is called which blocks me out for about 120msec which my application can’t stand. I know it’s not supposed to work this way but I have yet to be able to figure out what the issue is. Any suggestions?

rtel wrote on Saturday, June 09, 2018:

Can you post how lwIP is implementing taskEnterCritical(). It should
call the FreeRTOS taskENTER_CRITICAL(), which will mask interrupts up to
configMAX_SYSCALL_INTERRUPT_PRIORITY only. If it is instead just
globally disabling interrupts in the core, rather than the NVIC, then
that would be the cause of you problem.

dwsexton wrote on Saturday, June 09, 2018:

The LWIP function is LOCK_TCPIP_CORE which calls sys_mutex_lock
which calls osMutexWait
which calls xSemaphoreTake
which calls xQueueGenericReceive
which calls taskEnter_Critical
which calls the Assembly code in portDisable_Interrupts which is defiend as vRaiseBasePri
which sets the basePri register. I have no visibility what it is stuffing in there as I have not figured out where the values are comong from, the inline ASM is
mov #0,#1
mov basepri,#0

dwsexton wrote on Sunday, June 10, 2018:

My bad - the issue I have been fighting for the last 2 days was not a code issue at all, it was due to semihosting and the jtag programmer. Once I disabled all semihosting messaging it works flawlessly. File that away in your synapsis for future reference.

rtel wrote on Sunday, June 10, 2018:

Thanks for taking the time to report back.