|Subject:||Re: [lwip-users] Assertion "memp sanity" failed at line 463 in../lwip_1_4_0/Src/core/memp.c|
|Date:||Mon, 19 Nov 2012 08:47:15 +0800|
Thanks for the answer.
Should have said LWIP 1.4.0
I understand is most likely a memory corruption.
I have checked the sys_arch code against every other example that I have been able to find and this matches the cortex M3 implementation in them all, I have found this at least to be very consistent.
The interrupt routine does call the memp to store the received packets, transmit uses its own circular buffer so doesn’t call any of lwip memory functions.
// We allocate a pbuf chain of pbufs from the pool.
p = pbuf_alloc(PBUF_RAW, len, PBUF_POOL);
What do you mean by must be configured correctly?
This is the hardest bit to determine as it is not really clearly defined anywhere.
I have looked at the examples with FreeRTOS and they vary slightly in the way they do things (Without a comment as to why) so this makes it hard to determine what is the correct way.
If you have any advice on the correct way to implement I am happy to hear.
As far as I can tell the memory routines are all wrapped in critical sections and these match the other examples.
PendSV and Systick for freeRTOS are both being set lowest priority, TCPIP task is being set mid range priority.
Any additional advice appreciated.
I faced with similar problem some time ago. Most likely it means that global memory was corrupted because of thread-safety problems in your sys port or freertos configuration or misuse lwip functions from interrupts. Check sys_arch_protect()/sys_arch_unprotect(), configKERNEL_INTERRUPT_PRIORITY and configMAX_SYSCALL_INTERRUPT_PRIORITY in FreeRTOSConfig.h (special attention for Cortex-M3 !) Also, if your application or driver call lwip memory functions from interrupts, keep in mind, that it's very restricted and must be configured properly in lwipopths.h
|[Prev in Thread]||Current Thread||[Next in Thread]|