Well, Christian, I don't have any expertise on the NO_SYS=0 world, but I can tell you that you normally don't "implemented the port function". You don't port lwIP to an OS unless you know exactly what you are doing, you normally get a port for your OS and ask your OS port maintainers when you have trouble. You should get a known good FreeRTOS port of lwIP first. If you have to port it yourself, then by all means try a known working lwIP app first !
> [...] LWIP ASSERT "pbuf_free: p->ref > 0" message. I don't understand > what this means and how I can find the reason. Well, if you read the documentation and explore the source code, you will learn what pbufs are and how they have a reference count to track the number of referers. If you do a search on pbuf.c in lwIP code, you'll see that string appearing only once, inside function pbuf_free(struct pbuf *p), at line 650 in the official 1.4.1 release, and it is in the following context: /* de-allocate all consecutive pbufs from the head of the chain that * obtain a zero reference count after decrementing*/ while (p != NULL) { u16_t ref; SYS_ARCH_DECL_PROTECT(old_level); /* Since decrementing ref cannot be guaranteed to be a single machine operation * we must protect it. We put the new ref into a local variable to prevent * further protection. */ SYS_ARCH_PROTECT(old_level); /* all pbufs in a chain are referenced at least once */ LWIP_ASSERT("pbuf_free: p->ref > 0", p->ref > 0); ref = --(p->ref); SYS_ARCH_UNPROTECT(old_level); You'll see that this is decrementing the number of references to a pbuf when called, and when that is 0, the pbuf will be freed. The assertion inside the SYS_ARCH_PROTECT/SYS_ARCH_UNPROTECT is checking that p->ref is indeed >0, so you don't try to free a pbuf that was already freed, and it checks this while trying to avoid other tasks to screw things up. So, even though I have no experience on NO_SYS=0 and I might be overlooking something, I can tell you that: - either your port is not good and it is messing things up, - you are not calling the stack from a single thread as requested, - or your application is broken and is trying to free an already freed pbuf. You can try to log p->ref before and after the lock to check if things are being screwed up, and you can track the pbuf_free caller to check if someone is passing a freed pbuf. _______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users