Can anyone explain why any STM32H743 Ethernet reception causes all the Rx buffer descriptors to be closed with DESC3 set to 0x00000000 and the RBU status flag set to indicate no more buffers available?

[hpipon957]

Hi

Working on the STM32H743ZI - Ethernet transmission is working but reception not.

As shown below there are 4 rx buffer descriptors set up. Each with the DMA ownership, generate interrupt on completion and buffer 1 valid set in DESC3. DESC0 points to a log word aligned reception buffer in the same memory area.

As soon as there is a single Ethernet (broadcast) reception this is what happens:

 

All 4 buffer descriptor control words are set to 0x00000000 (by Ethernet DMA controller to indicate that it has received something).

DMACSR signals 0x00000080 (receive buffer unavailable) since all buffer descriptors are now full and presumably the Ethernet controller wanted to write more.

DMADSR signals that the receiver is suspended due to no more buffer descriptors being available.

There is no rx interrupt generated so the buffers can't be cleared by code. Also it is seen that no data was written to the first buffer descriptor's buffer (still all at 0x00) and no DMA errors are signaled.

It is as if the Ethernet DMA is trying to save the data but something is limiting the size fo each buffer to 0 (so it doesn't save anything, closes the buffer but is not complete and moves to the next - then repeats until all buffer descriptors are closed, but the frame not complete).

Note that DMACRxCR is set to a full Ethernet frame size and I don't find any further rx length limitations that may control this.

As noted, Tx works as expected - but the Rx operation not yet...

Can anyone explain what causes this so it can be corrected?

Thanks

Regards, Mark

[Pavel A.]

@hpipon957 This is not what most of users see on STM32H743ZI. There are many known issues but not this. And you aren't providing enough details about the board, PHY (is it the Nucleo?) and which ETH driver are you using.

[hpipon957]

Hi

Nucleo-H743ZI with LAN8752A. PHY is not a problem - it communicates and link up/down responds as normal.

Driver is an adapted version (with a few changes to suit the H7) of one that has been used successfully for 10 years on STM32F parts.

MPU is disabled and AXI RAM is used for buffer descriptors and data buffers.

Ethernet Tx worked without any problems but the Ethernet Rx behaves as described. The goal is to work out what causes it to behave like this in order to understand the issue and then fix it so that existing STM32F products can work on the STM32H with minimum changes.

Regards

Mark

[hpipon957]

Hi

It has been identified that the BUFV1 flag defined in the header was set to the wrong bit, meaning that no valid buffer flag was set in the buffer descriptor.

Once that was corrected the reception behavior started to be as expected and the TCP/IP operation is now successful.

Therefore the reason for the behavior is now known and also the behavior that can be expected is known when the valid buffer flag is not set!

Regards

Mark

[Pavel A.]

> AXI RAM is used for buffer descriptors and data buffers.

This can be the problem. ST examples use the D2 RAM -which should be enabled in user code, it is not enabled after reset. Align RX buffers on 512 bytes (this seems to work

for me, though not documented)

[hpipon957]

Hi Pavel

According to the data sheet 4 byte alignment should be OK and that is what I have used.

I tried in D1 and D2 and AXI RAM but didn't notice any difference, although I had DMA errors when trying in DTCM (which is to be expected since the Ethernet DMA has no access to this bus - see below).

As noted, the error was a bad buffer flag and since that has been corrected the embedded web server has been working normally.

There may be opportunities to optimise the memory usage so the use of the other RAM banks will be reviewed as things further develop.

Regards

Mark

[Pavel A.]

Then I'd suggest to find a ST example closest to your need (with or without RTOS, TCP or UDP....) and make it work on your board with minimal possible changes. If you get RX working, the problem should be in your software. Else it may be in hardware.

[hpipon957]

Pavel

As stated twice in the last two posts all is now operating correctly after correcting the buffer flag in the buffer descriptor. (i.e. Ethernet driver, TCP/IP stack,web server and RTOS).

Regards

Mark

[Piranha]

> Align RX buffers on 512 bytes (this seems to work for me, though not documented)

There is no such requirement. DMA has a requirement of 4 byte alignment and, when SCB_***() functions are used, those require alignment to D-cache line size - 32 bytes. Of course 512 bytes will also work, because it satisfies both of those. But, if it doesn't work with 4/32 byte alignment, you can be sure the code is broken.

[Piranha]

Just in case... While it seems this is not directly relevant for your code, it's probably still worth checking your code for these issues:

https://community.st.com/s/question/0D50X0000BOtfhnSQB/how-to-make-ethernet-and-lwip-working-on-stm32