Re: [lwip-users] lwIP with FreeRTOS memory problem

[FreeRTOS Info]

On 28/11/2016 02:17, pekez wrote:
> Hello people,
>
> I've been trying to figure out how lwIP uses memory and it's really
> important to know exact (or maximum) amount of memory that lwIP uses. I
> am using lwIP v1.4.1 with FreeRTOS v8.2.3 on ZYNQ custom board. Right
> now, I am working with application examples provided by Xilinx (XAPP1026
> <https://www.xilinx.com/support/documentation/application_notes/xapp1026.pdf>).
> On ZYNQ board, I am running iperf <https://en.wikipedia.org/wiki/Iperf>
> server, and on PC iperf client.
>
> When both MEMP_MEM_MALLOC and MEM_LIBC_MALLOC are 0 then everything
> works completely expected. However, when I set MEMP_MEM_MALLOC to 1
> (according to RAM usage article from lwIP wiki
> <http://lwip.wikia.com/wiki/Lwipopts.h>), so that every piece of
> dynamically allocated memory comes from heap of MEM_SIZE size,
> application always crashes, no matter how big or small MEM_SIZE is (I
> have a lot of RAM, so I tried to put MEM_SIZE to even more then 20 MB!).
> Application crashes because two of FreeRTOS asserts fail, I get these
> two prints: "Assert failed in file queue.c, line 1224" and "Assert
> failed in file port.c, line 424". According to call trace (which I
> provided in attachments), it crashes when XEmacPs_IntrHandler (I am
> using Xilinx layer 2 drivers) tries to allocate memory for pbuf.
>
> Is this problem even related to lwIP or maybe to FreeRTOS or Xilinx
> drivers, what do you think? I am also providing the entire lwipopts.h,
> so that you can see whether some other options need to be changed in
> order to make application work with MEMP_MEM_MALLOC set to 1.

It sounds like you are trying to call malloc from an interrupt handler - 
which you can't do [in FreeRTOS] as the malloc is thread safe but not 
interrupt safe. One solution, albeit with a time penalty, is to use a 
deferred interrupt handler, where the IRQ does nothing more then unblock 
a very high priority task and clear the interrupt. Then the interrupt 
will return directly to the unblocked task to perform the actual 
processing necessary (the processing that was deferred from the 
interrupt). You can then optimise it so only interrupts that want to 
allocate memory get deferred to a task.

Example code snippets of how to do this can be found on the following 
page: 
http://www.freertos.org/RTOS_Task_Notification_As_Counting_Semaphore.html

Alternatively provide an additional heap for use just by the ISR so you 
don't get re-entrancy problems, or update the heap_n.c file 
(http://www.freertos.org/a00111.html) so it uses interrupt safe critical 
sections rather than task only critical sections (although this last 
option could make interrupts less responsive).

Regards,
Richard.

+ http://www.FreeRTOS.org
The de facto standard, downloaded every 4.2 minutes during 2015.

+ http://www.FreeRTOS.org/plus
IoT, Trace, Certification, TCP/IP, FAT FS, Training, and more...