[lwip-users] sporadic PCB corruption

[Sandra Gilge (ADATIS)]

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 to memory. Or am wrong here?

If it is a threading issue: Is there a possibility to check this? What I want to try is to store the threadID of the
TCPIP-Thread and compare this with the current thread ID inside all functions that modify the TCP-PCB Pool lists.
Is this worth to try? Or is there a better solution to test this.

But I can't imagine where I should call tcpip functions directly. I'm using the sockets API in the application. And in the
driver I use the callback functions.

Best regards,

Sandra

Am 26.01.2017 um 14:34 schrieb address@hidden:

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 starts aligned (so cache operations don't influence memory 
*before* that pool).
However, you still have two possible problems:
a) normally you flush the cache before TX and invalidate it before RX. 
However, you do so on the *data* only. Now the PBUF_POOL contains memory 
where "struct pbuf" is directly followed by the data buffer. Since 
"struct pbuf" is 16 bytes, cache operations on the data will corrupt the 
struct (when 32 byte alignment is required).
b) the last pbuf might not end on a 32 byte boundary, so 
flushing/invalidating it might corrupt the next pool.

You seriously should fix this! However, I'm not convinced this is the 
reason for the tcp pcb list corruption, as the PBUF_POOL memory normally 
should be quite far away from the TCP_PCB pool... (unless your linker 
places them near each other).

Being like that, I'd still favour the "threading violation" problem...