How MAC, FIFO and DMA descriptor is dealing with received frames from and UDP client using HAL libraries?

[genisuvi]

I have read the datasheet where this part of ethernet is explained. But I have not clear of all taking it to a practical case.

Case:

1. Client is sending constantly requests to the stm32f207 HAL based with Lwip stack and no RTOS udp server.
2. Client requests has between 2 and 20 bytes of data payload.
3. Every request payload is put in a frame. Every frame has its overload bytes due to MAC, ip and udp headers.

I'm wondering what happens with those frames when they achieve MAC controller and the follwing blocks: FIFO and DMA, since FIFO has 2Kbytes, and MAC sends the frame to the DMA by a frame descriptor (struct type). But FIFO are in the middle of these two blocks and I don't know what FIFO does with the DMA descriptor.

So please, let me know if something that I'm go to say is wrong:

1. As the payload are very short I guess that received frame will be treated being not truncated.
2. It is only one ethernet dma descriptor object for allocating received data from remote hosts. (not an array of descriptors)
3. From MAC reception MAC controller puts the whole frame into the descriptor frame register.
4. After this, if FIFO is empty I guess the descriptor is passing directly to the DMA and DMA is passing inmediatly to the memory system
5. If FIFO is not empty I don't know how descriptor works in this case.

My questions:

1. Every received frame from remote host (client) will be put inmediatly into the dma descriptor by de MAC controller or could MAC controller be waiting for more than one frame and put more than one into the descriptor until get descriptor register full?
2. If yes, is it a limit of number of frames or number of total bytes that can be inside of a DMA ethernet descriptor?
3. What is done by the FIFO with this descriptor? For me has more sense that MAC controller is passing the frames to the FIFO and when DMA ends of sending the frames to the memory system the FIFO is giving its bytes to the DMA.
4. In the case of not empty FIFO frames are allocated inside it, but FIFO block can't be dma descriptor own, so how does FIFO for writing frames on this descriptor? Who is the descriptor owner? Is it DMA owned, is it MAC owned, who writes FIFO frames into descriptor if FIFO has never got the de descriptor own...

thanks in advance

[Bob S]

I'm not sure why you are asking about (or care about) low level Ethernet details when you have HAL/LwIP code that handles all of that. LwIP should take care of buffering the incoming packets (up to the number of buffers that you configured LwIP to use).

Are you having some issue with handling the incoming packets or sending the response packets? Or are you just curious as to how the underlying hardware works?

[Bob S]

Never mind - I just saw your other 3 or 4 posts about your Ethernet issues.

[genisuvi]

Thanks for your observation.

Because of:

- after some time working fine DMA is owning the Ethernet descriptor for ever and MAC has stopped receiveing data but no frame error is detected.

- HAL could be adding some kind of issues to ethernet communications (they has been reported for lot of users and recognized by technical support).

- Lwip has a lot of configuration parameters related with packet sizes, buffers, etc.. that must be defined. May be my ethernet problems comes from some bad configuration.

Having into account that my data payload is to short, I'm trying to answering who of these 3 parts/blocks (DMA-FIFO-MAC) has the problem and which one. Why do DMA suddenly decide not to free the descriptor to the MAC.

[genisuvi]

As you say I would like to define the number of LwIP buffers correctly and being consistenly with stm32f207 ethernet architecture, behaviour and capability.