lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] ERR_MEM when sending large data, LWIP stats show no err


From: Adrian Figueroa
Subject: Re: [lwip-users] ERR_MEM when sending large data, LWIP stats show no error
Date: Fri, 15 Sep 2017 10:15:43 +0000

Beware: long text

I will try to write a new driver or repair the current one. However, I have 
some questions for a better understanding of the underlying principles. At the 
moment I only care about transmitting.

Let's start with the initialization of the DMA transmit buffers. There is a 
list of chained DMA transmit descriptors, as they seem to be called. There is 
always four of them, this is hard coded. Each of the buffers points to the next 
one, and the last points back to the first. So, this is a circular buffer 
(Initialization happens in HAL_ETH_DMATxDescListInit(...)).

Each of the buffers has fields for data pointers and data length (and some 
others).

Now, there is the low_level_output(...) function that does the actual 
transmission. It picks the first DMA transmit descriptor and writes data to 
where its data pointer points to. It does this by using memcpy(...) to copy 
from the pbuf payload field to the data field of the descriptor. This seems 
unnecessary, but will it actually break transmission and cause lost packets? It 
will just slow it down a bit.

Anyway, in low_level_output(...), pbuf data is written to DMA descriptors in a 
loop. The loop iterates over all pbufs that are chained together.

Incoming pbufs are always a chain of two pbufs. One is 54 bytes long (header?) 
and the following pbuf is 1460 bytes (the TCP_MSS size).

After all the memcpy-ing, the DMA descriptor buffer is always filled with 1514 
bytes. My packets are always the same size.

For sending, HAL_ETH_TransmitFrame(...) comes next. It checks, how many DMA TX 
buffers were used for the packet to be sent. This seems stupid, as 
low_level_output(...) knows how many of them it allocated. It could just pass 
this number on to HAL_ETH_TransmitFrame(...) but it does not.

There is a check, if a DMA descriptor is already in use or not before writing 
to it. So, I assume that it does not happen that a descriptor is overwritten. 
However, a DMA descriptor is marked as "in use" only in the 
HAL_ETH_TransmitFrame(...) function. So, if low_level_output(...) makes use of 
more than four DMA descriptors, some WILL be overwritten.

Still:

      if((DmaTxDesc->Status & ETH_DMATXDESC_OWN) != (uint32_t)RESET)
      {
        errval = ERR_USE;
        goto error;
      }

Is not triggered anymore, even though I am still losing packets. This is 
because my pbuf chains are never long enough to fill four DMA descriptor 
buffers.

Also, the pbuf chain never causes any memory errors. So, the pbufs are probably 
cleared fast enough. I am not sure where to look next. If I got something 
wrong, please correct me.

Thanks,
Adrian

-----Ursprüngliche Nachricht-----
Von: lwip-users [mailto:address@hidden Im Auftrag von Adrian Figueroa
Gesendet: Friday, September 15, 2017 8:31 AM
An: Mailing list for lwIP users <address@hidden>
Betreff: Re: [lwip-users] ERR_MEM when sending large data, LWIP stats show no 
error

That memcpy is also used on the F7. The drivers are probably the same:

/* Copy data to Tx buffer*/
memcpy( (uint8_t*)((uint8_t*)buffer + bufferoffset), 
(uint8_t*)((uint8_t*)q->payload + payloadoffset), (ETH_TX_BUF_SIZE - 
bufferoffset) );
      
Adrian


-----Ursprüngliche Nachricht-----
Von: lwip-users [mailto:address@hidden Im Auftrag von address@hidden
Gesendet: Thursday, September 14, 2017 5:46 PM
An: Mailing list for lwIP users <address@hidden>
Betreff: Re: [lwip-users] ERR_MEM when sending large data, LWIP stats show no 
error

Adrian Figueroa wrote:
> I can see some errors in low_level_output() in ethernetif.c.
>
> This fails:
>
>        if((DmaTxDesc->Status & ETH_DMATXDESC_OWN) != (uint32_t)RESET)
>        {
>          errval = ERR_USE;
>          goto error;
>        }

I don't know the F7 driver, but my F4 driver seems to have the same code lines.
It's worse there since they even memcpy from pbufs to the DMA descriptors... :-(

Simon

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

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]