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...
_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users