That call stack does not mean the corruption happens in this call stack.
For debugging, can you simply call memp_free on the tcp PCB from your
application thread? If the sanity check already hits you there, then it is
most probably your application's problem.
If you are on a platform with HW
Hallo Simon,
The corruptions seems to come from the shutdown function. I tracked this
down with the MEMP_SANITY_CHECK.
I only got problems with the LWIP Stack when using the webserver. I've got
other Applications which use TCPIP heavily didn't cause any problem (like
JPEG/MJPEG streamer where I
Hallo Simon,
Indeed I call a "cache invalidate" after the DMA has written data from
EMAC to pbuf and do a "flush" before
the DMA writes to the EMAC.
The cache is configured as write-through cache. As far as I know there
can nothing be corrupted because
write operation always writes directly
Sandra Gilge (ADATIS) wrote:
there is following line in cc.h:
extern u8_t memp_memory_PBUF_POOL_base[] __attribute__ ((aligned (32)));
I checked the address of memp_memory_PBUF_POOL_base it is 32byte aligned
That might not be enough. With this, you only have ensured the PBUF_POOL
memory
Hallo Simon,
regarding cache:
the option
#define MEMP_SEPARATE_POOLS1// for PBUF_POOL
alignment to cache line size
is set in lwipopts.h
also
there is following line in cc.h:
extern u8_t memp_memory_PBUF_POOL_base[] __attribute__ ((aligned (32)));
I checked the address
Sandra,
I'm afraid problems like yours happend often in the past and only seldom
there has actually been a problem in lwIP. Most of the time, it's wrong
usage of lwIP (by the lwIP port).
Now I don't know the zero copy driver from Stephane, but zero copy
imposes some special requirements on
