Socket/FreeRTOS/external interrupts not working together

[ola_gook]

(Using S32DS3.5, S32K344, RTD4 latest and FreeRTOS latest)

After getting ethernet working under FreeRTOS using static and dynamic memory allocation, I have also managed to get socket handling working, mainly through the chargen example of the tcpip stack examples. So far no problem.

The problem is that when integrating this code with my current codebase, ISR handling is no longer working as expected.

Another community issue indicates so increase the stack, which I have tried without any change in behavouir (Solved: RTD 4.0.0p01 FlexCAN with FreeRTOS asserts in OsIfSuspendAllInterrupts() - NXP Community)

The problem that occurs is that the PIT ISR enters a critical region, which in turn ends up in the vPortEnterCritical function provided in the FreeRTOS code.

A clear comment in this function states that it is not to be called from an ISR context, which is exactly what is happening here. Thus, the configAssert statement hangs the application.

I have tried to find an example of using FreeRTOS while also having ISRs from external sources working but can only locate LED examples.

My current configuration uses PIT and CAN and both of these behave the same as both use critical regions.

Any suggestions greatly appreciated.

Regards,

/Ola

[PetrS]

Hi,

you can try to increase task's stack or heap size. But probably the issue is due to taskENTER_CRITICAL() and taskEXIT_CRITICAL() must not be called from an interrupt service routine (ISR) - see taskENTER_CRITICAL_FROM_ISR() and taskEXIT_CRITICAL_FROM_ISR() for interrupt safe equivalents; https://www.freertos.org/taskENTER_CRITICAL_taskEXIT_CRITICAL.html

BR, Petr

[ola_gook]

Thank you for your reply, although it did not help much. I wil ltry to be more clear:

As I wrote in my post, I already tried changing the stack and heap to no effect.

As you say, the problem is because of the critical region but this is called from inside the RTD code and should not be changed by me. I cannot see anywhere that the application developer can affect this.

So, again, is there an example of LWIP (specifically socket handling), FreeRTOS and external interrupts working together?

Or is this combination not expected to be supported?

Just to be super clear:

1. As soon as the external interrupt triggers, the ISR is triggered which in turn enters a critical region. No way of affecting this through any configuration settings. This is pure RTD code.
2. Next, the critical region is executed and ends up in the above mentioned piece of code, which clearly states that it cannot be called from an ISR context.

The specific critical region code is "generated" by a series of #defines in LWIP/FreeRTOS, again something I cannot affect as far as I can tell.

Please advice.

[PetrS]

Hi,

my understanding is a xxxFromISR() version api should be used.
I was noticed that the RTD team already raised a ticket for this issue and it will be fixed in the next releases in the future.
We cannot serve more for now.

BR, Petr

[ola_gook]

I see. So for now this is simply not supported then?

Or do you or the RTD team have a suggested mitigation?

There are quite a few files included in this so hard to tell which change is best.

RTD files as well as FreeRTOS files.

Affected files are:
Pit_Ip.c
SchM_Gpt.c
OsIf_Internal.h
task.h
portmacro.h
port.c

Regards