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 <lwip-users-bounces+greenwoodg=leidos....@nongnu.org> On
Behalf Of Simon Goldschmidt
Sent: Thursday, September 27, 2018 10:49 PM
To: lwip-users@nongnu.org
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
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
