I have tested the udp_echo demo application within KSDK2.0 on a FRDM-K64F board and find it functions as expected.
this demo is normally located in the FRDM-K64F SDK at \boards\frdmk64f\demo_apps\lwip\lwip_udpecho\freertos
I am now attempting multithreading with lwip by copying the udp_echo thread to make a second udp echo thread and binding it to a different port (50002). I have been unable to get both threads responding to udp packets.
From what I can see by setting breakpoints, the second thread to be created does not start and I have not determined the cause. I have tried setting the second thread to a higher priority, but that didn't resolve the issue.
If I create udpechothread#2 before udpechothread#1 , udpechothread#1 doesn't start, and vice versa.
From what I have read it should be feasible to run a second thread with lwip as the netconn layer allows it. I have not yet seen documentation or example code that would help to resolve the issue.
Is there something I need to alter in lwip_udpecho_freertos_frdmk64f/lwip/src/include/lwip/opt.h to allow multithreading?
Should I consider using a different TCP/IP stack?
Thanks for sharing of this issue.
It is probably caused by small heap size.
Default stack size for udpecho_thread is 3000 words. That is mean 12000 bytes. More at http://www.freertos.org/FAQMem.html#StackSize
Heap size is defined by project symbol _heap_size_= 24576. This value is in bytes.
If the task is duplicated, required space for task stacks is 24000 bytes. Creation of second task fails, because there is not enough memory for stack allocation.
This can be solved by heap size increase (_heap_size_=40000).
The problem is indeed caused by lack of available memory, however the solution I found is different from what you described.
I increased the value of configTOTAL_HEAP_SIZE defined in FreeRTOSConfig.h from ((size_t)(24 * 1024)) to ((size_t)(40 * 1024)). After compiling I found the section m_data had insufficient space, so I changed the linker config to increase the length of m_data to 0x00020000. I also decreased the length of m_data_2 by 0x10000. The application now performs as expected.
Checking the return value of sys_thread_new(..) is also advisable.
I found in the linker file that __heap_size__ is set to 0x1000 ( 4096 bytes ) and this is ok.