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