[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Assertion "memp sanity" failed at line 463in../lwip_1_4

From: Barry Andrews
Subject: Re: [lwip-users] Assertion "memp sanity" failed at line 463in../lwip_1_4_0/Src/core/memp.c
Date: Mon, 19 Nov 2012 12:01:21 +0800

Thanks for the prompt and precise response.


As it turns out I just found out about the LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT and am now testing with this set to 1.

Previously this was 0 (My transmit routine can free memp if it needs to queue a packet)


All the others I have set as per your suggestions.

configKERNEL_INTERRUPT_PRIORITY is set to 7 << 5 for the TI stellaris.


Am now thrash testing and will let you know how it goes.

Once again thanks for the detailed response, much appreciated.



Barry Andrews


From: address@hidden [mailto:address@hidden On Behalf Of Artem Pisarenko
Sent: Monday, 19 November 2012 11:46
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Assertion "memp sanity" failed at line 463in../lwip_1_4_0/Src/core/memp.c


So you are using FreeRTOS and Cortex-M3 ? I'm 99% sure your interrupt routine causes problems and I can help you. (I recently faced with very similar issue).

1. define LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT to 1 (see description in src/include/lwip/opt.h). This will let you call safely mem_malloc()/mem_free() functions or other lwip functions which imply calls to them (such as pbuf_alloc()) from interrupt context.
2. Make sure your sys arch protection implementation does taskDISABLE_INTERRUPTS/taskENABLE_INTERRUPTS (or portXXX equivalents).
3. Make sure that numerical(!) value of interrupt priority is equal to or greater than the configMAX_SYSCALL_INTERRUPT_PRIORITY setting in your FreeRTOSConfig.h. Also be warned that configMAX_SYSCALL_INTERRUPT_PRIORITY must not be set to 0. Use only priorities 1 and above.
4. Make sure you defined priorities values correctly. It's easy to confuse with them in cortex-m3 because there are no standartized way across different tools/libraries to treat them in one manner. FreeRTOSConfig.h macro values must be defined as ready shifted: (prio << (8 - __NVIC_PRIO_BITS)), where prio is number from 1 to <max priority level>. But the way you initialize your interrupts may vary. For example, if you use STM32 CMSIS library, then you must call NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4) before vTaskStartScheduler() and in NVIC_Init() structures you must assign priority as preemtion priority and set subpriority to 0.
5. Make sure you defined configKERNEL_INTERRUPT_PRIORITY to 255 or (255 << (8 - __NVIC_PRIO_BITS))

If all above requirements are fulfilled then everything must work correctly. I'm not sure is #1 essential or not. :)

See http://www.freertos.org/RTOS-Cortex-M3-M4.html for details.

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.




Barry Andrews


reply via email to

[Prev in Thread] Current Thread [Next in Thread]