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:lwip-users-bounces+adrian.figueroa=tu-dresden...@nongnu.org] Im Auftrag von Adrian Figueroa Gesendet: Friday, September 15, 2017 8:31 AM An: Mailing list for lwIP users <lwip-users@nongnu.org> 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:lwip-users-bounces+adrian.figueroa=tu-dresden...@nongnu.org] Im Auftrag von goldsi...@gmx.de Gesendet: Thursday, September 14, 2017 5:46 PM An: Mailing list for lwIP users <lwip-users@nongnu.org> 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 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 _______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users