Re: [lwip-users] EXTERNAL: Re: Pbuf Assert

[Greenwood, Gregory A.]

The project is based on the STM32H743_Eval application project code 
LwIP_UDPTCP_Echo_Server_Netconn_RTOS.  I have added additional functions for 
UART communications and I am not using the UDP echo function.  I reworked the 
TCP echo function to act as a TCP server which responds to data requests from a 
HOST.  This is all based on STM32Cube_FW_H7_V1.3.0.  The project base was built 
from CubeMX and the appropriate code added from the application example 
previously specified.  I do not know for certain and I am not sure how to drive 
to root cause, but I suspect that the LCD driver processes, which depends on 
DMA between the LCD and External RAM, is somehow corrupting the External RAM 
and DMA processes for the Etherent.  The purpose of the top post was not to 
make anything unreadable but to draw attention away from LWIP and yes I have 
posted on the STM32 MCU forum. 

-----Original Message-----
From: lwip-users <address@hidden> On Behalf Of Simon Goldschmidt
Sent: Thursday, September 27, 2018 10:49 PM
To: address@hidden
Subject: EXTERNAL: Re: [lwip-users] Pbuf Assert

Greenwood, Gregory A. wrote:
> I have stopped the problem but I am not sure of the root cause.
> It does not seem to have anything to do with LWIP itself.  I was using 
> a utility feature supplied by STM that prints debug messages to the 
> LCD screen on the evaluation board.  When I reduced the number of 
> messages and text length, the Assert stopped occurring.

This top-posting somehow makes the whole thread unreadable...
 
> [..]
> I cannot figure out why I am getting an Assert in pbuf.c at line 747:
>   LWIP_ASSERT("pbuf_free: p->ref > 0", p->ref > 0); I know the obvious 
> answer, in the p->ref cannot be 0.
> The problem is that I cannot tell what would cause p->ref to be 0.
> And this is occurring in a while loop that depends on p != NULL.
> I am using the LWIP that comes from CubeMX for STM32H7.
> LWIP version 2.0.3.

Either you're double-freeing a pbuf (like Patrick alread wrote). In that case, 
the changed debug messages might just have changed the runtime behaviour in a 
way that hides this bug.

Or you just might have a memory corruption issue where the debug output code 
overwrites arbitrary memory.

In any case, this is not a bug in lwIP. Have you asked in ST specific forums 
already?

I haven't yet found the time to test the new CubeMX release where they finally 
managed to include 2.0.3, so I can't tell if it is correct. But this is on my 
list... How did you create the project, did you use an example project or a 
project completely generated by CubeMX where you enabled the lwIP library?

Simon

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users