ETH DMA stuck in ''waiting for status''

[danicek]

Posted on September 21, 2016 at 15:36

Hello.

I'm working on a project, running on STM32F427IIH6, which uses FreeRTOS 6.1 and LwIP 2.0. There are several TCP clients and TCP/UDP servers and it's running with no issues. But after adding UDP client,

low_level_output occassionally fails at very first ARP packet, involved by lwip_getaddrinfo called by the UDP client. If it doesn't occur at start, whole system can run ''forever''.

Settings (state of registers just before first write):

MACCR == 0x0000800C // Rx and Tx enabled

MACFFR == 0x00000040 // PCF == 1

MACFCR == 0x00000080 // Zero quanta disabled

All other MAC registers except of MII and MAC address registers are zero.

DMABMR == 0x02C16080 // 32b long, address aligned, fixed burst; 2:1 Rx:Tx priority; enhanced descriptors

DMAOMR == 0x02202006 // Both Rx and Tx are started, store and forward mode. OSF mode used for Tx

DMAIER == 0x00010040 // Only Rx interrupt and summary enabled

DMASR == 0x00660004 // Rx is waiting for data, Tx is suspended and waiting for send command

Descriptor and buffer address registers have proper values, other registers are zero

I use LAN8720Ai connected via RMII and its' registers don't change since this time.

I use 5 Tx chained descriptors, all of them have set TCH bit in word 0 and filled both pointers, everything else is 0.

Success: 5 frames sent, ETS bit in DMASR is set, first 2 descriptors have set FS and LS bits and data length. Nothing else changed.

Fail (differences to success in bold): No frame sent, ETS bit in DMASR is set, TBUS is reset and TPS has value of 2, which means, that Tx DMA FSM is ''Running, waiting for status''. All 5 descriptors have set FS, LS and OWN bits and data length. DMACHTDR and DMACHTBAR now point at second descriptor and its' buffer.

DMA doesn't send data to MAC for some reason and when sw tries to send TX_DESC_NUM + 1 frames, I get the error. What's the ''status'', which is DMA ''waiting for''? I haven't found anything about it in the reference manual.

#stm32f4-eth

[waclawek.jan]

Posted on September 22, 2016 at 09:24

I'm by no means an expert, but is link reliably up at the moment the first (ARP) packets are sent out?

JW

[danicek]

Posted on September 26, 2016 at 09:23

PHY is linked and all its' registers are the same in both cases - success or fail.

I even managed to start sending frames by brute eth reinit, but then I couldn't receive anything as I can't restart lwip at this point.

Also, it's not caused by HW, I tried it on 2 different boards and other guys tried it on their HW too.

The question still is: What means ETH_DMASR_TPS_Waiting why the DMA is stuck in this state and how to avoid it or push it to ETH_DMASR_TPS_Reading?