Re: [lwip-users] illegal RTOS API call from ethernet receive interrupt

[Michael Steinecke]

Hello Peter
Your Stack Trace Locks like your Ethernet Driver or ethernetif.c is not well implemented. Usually you should pass the received packet from the IRQ context to a task, which calls LWIP.
www.freertos.org/xTimerPendFunctionCallFromISR.html
Or use a queue for this. But be careful, the IRQ should only notify the existence of new packages and in the task you need to read as long as there is data available otherwise you will loose packages on heavy load. 

Kind regards
Michael

Am 19. November 2015 17:41:54 MEZ, schrieb Peter Ruesch <address@hidden>:

Hello,

 

I’m doing some tests with lwip (1.4.1) and FreeRTOS (8.2.1) on a Kinetis K65 device.

From the beginning was able to ping the target reliably. For some performance tests I added the lwiperf server from the mainline repo.

 

I noticed, that if I was continuously pinging the target and ran a iperf test in parallel, the system stopped responding. When I halted the program execution, I was finding the program stuck in FreeRTOS runtime assertion triggered, (at least in understanding) because I was calling FreeRTOS API functions from within the Ethernet receive interrupt context.

 

This (presumably) illegal call to the API function happens because of a mutex guarded malloc. This does not exactly seem wrong. But it leads to this “stuck in assertion” problem.

 

I have uploaded the stacktrace as screenshot.

http://postimg.org/image/bb94dm4nj/

 

if I alter the RTOS settings so that the assertion is not active anymore, I can run iperf and ping in parallel for hours.

Why does this RTOS API function need to be called from within the receive interrupt?

 

Best regards

Peter

lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.