NUCLEO-N657X0-Q ethernet DMA issue

[ACR]

Hello ST community,

 

I configured my project in STM32CubeMX 6.17.0 and use STM32CubeIDE 2.1.1 to debug. 

The goal of the program is to receive a raw ethernet frame.

I followed this tutorial, of course I adapted the pins to NUCLEO-N657X0-Q, and I skipped the part with the transmission, I didn't change anything in the HAL_ETH functions.

 

I am sending from the PC (I can see that the frame is sended with wireshark):

from scapy.layers.l2 import Ether 
from scapy.packet import Raw 
from scapy.sendrecv import sendp 
#Terminal ipconfig /all 
dst_mac = "00:80:E1:00:00:00" 
src_mac = "AA:79:39:37:92:EA" 
payload = bytes([0x01] * 86) 
frame = Ether(dst=dst_mac, src=src_mac, type=0x88B5)/Raw(payload) 
sendp(frame, iface="Intel(R) Ethernet Connection (13) I219-LM", verbose=True)

I placed a breakpoint in :

void HAL_ETH_RxCpltCallback(ETH_HandleTypeDef * heth)
{ 

}

This callback should be executed when an Ethernet packet is received, but it never happened.

I also tried by defining USE_HAL_ETH_REGISTER_CALLBACKS 1U in stm32n6xx_hal_conf.h.

Thankfully at the end of the tutorial, there are debugging tips, which led me to conclude that the PHY link is up and correctly initialized. 

The Debug status register (ETH_DMADSR) has the value 0x40400, that means the Rx descriptors for both channels are in suspended state, that they are not available. 

The SR bit of DMAC0RXCR is set and so indicates that DMA tries to acquire the descriptor from the receive list and processes the incoming packets. 

The CDE bit of DMAC0SR (channel 0 status register) is equal 0x0, that indicates that the DMA Rx engine didn't face a descriptor error.

The value of ETH_DMADescTypeDef *dmarxdesc (the address of the descriptor) is the same as the DMAC0CARXPR the register that contains the address of the current application receive descriptor.  

 I noticed that I couldn't find in the linker script STM32N657X0HXQ_AXISRAM2_fsbl.ld under section .RxDecripSection and .TxDecripSection. Is it normal ?

 

ETH_DMADescTypeDef DMARxDscrTab[ETH_DMA_RX_CH_CNT][ETH_RX_DESC_CNT] __attribute__((section(".RxDecripSection"))); /* Ethernet Rx DMA Descriptors */ 
ETH_DMADescTypeDef DMATxDscrTab[ETH_DMA_TX_CH_CNT][ETH_TX_DESC_CNT] __attribute__((section(".TxDecripSection"))); /* Ethernet Tx DMA Descriptors */

 

I would appreciate if someone know a bit more about that kind of issue.

 

Thank you!

[STackPointer64]

Hello @ACR, and Welcome to ST Community!

That declaration is not present by default. You add it manually to instruct the compiler to place your descriptors in a specific memory section. For example, you may want the descriptors to be in SRAM if you have configured a custom memory zone in the MPU, although that was not needed in that example. However, if you inspect other Ethernet examples using middlewares such as LwIP and NetXDuo on high-performance MCUs that include an MPU, you will see that most of them add this memory declaration in the linker file.

Best regards,

[ACR]

Hello @STackPointer64,

 

Thank you for helping.

The lines

ETH_DMADescTypeDef DMARxDscrTab[ETH_DMA_RX_CH_CNT][ETH_RX_DESC_CNT] __attribute__((section(".RxDecripSection"))); /* Ethernet Rx DMA Descriptors */ 
ETH_DMADescTypeDef DMATxDscrTab[ETH_DMA_TX_CH_CNT][ETH_TX_DESC_CNT] __attribute__((section(".TxDecripSection"))); /* Ethernet Tx DMA Descriptors */

are automatically generated by STM32CUBEMX, I didn' add these. 

 

It forgot to mention it, but I tried to add the following lines in STM32N657X0HXQ_AXISRAM2_fsbl.ld according to this example (link):

 . = ABSOLUTE(0x341F0E00);
 *(.RxDecripSection)

 . = ABSOLUTE(0x341F0EC0);
 *(.TxDecripSection)

 } >RAM AT> ROM

 

The only effect is that now the current application receive descriptor pointer is equal to this value.

The state of the Rx descriptor is still suspended.

I do not use MPU.

And before writing those lines in the linker script, I also got an address in this register which was 0x341c0098 (most certainly generated by STM32CUBEMX). I also found .RxDecripSection in RMII_PTP.v0_FSBL.map and the address was 0x341c0098.

under Debug/RMIIv0_FSBL.map

under Debug/RMIIv0_FSBL.list

And the first Descriptor Address should be between 0x34064000 and 0x341FFFFF according to STM32CUBEMX.

But in the reference manual AXISRAM2 beginns at 0x34100000.

 

Also there is in STM32CUBEMX no possibility to configure the start address of the Rx Buffer. 

 

 And as I said I didn't enable MPU, or any caches:

Maybe the Heap Size is to short  (I choose a bit more than 4*Rx Buffer Size)?

 

 

What would you suggest in this regard?

Best Regards,

 

[ACR]

Hello @STackPointer64,

 

I have made some corrections concerning the attribution of the address for the descriptors, now I can see them in my linker script. 

 

(.RxDescripSection and .TxDescripSection are also defined under SECTIONS)

Nevertheless it came to another issue, I had to double the length of both descriptor, from 96 to 192. I don't understand why the size isn't enough. The size of a section is 96 and the descriptor length is 4. 

That are the default values actually. When I set the size to 192 in STM32CUBEMX in the Memory Management it changes te descriptor length to 8.

I gave up for the moment the reception of a raw frame, I am trying now to transmit a raw frame to the pc in polling mode. I am still using this example.

 

In Debug, I took a look into the DMA registers, and now I still notice in the DMADSR the Suspended Mode for receive Channel 0 and 1  and now for transmit Channel 0 also. 

 

I have THE TBU bit set to 1 in ETH_DMAC0SR, which means that the transmit buffer is unavailable. 

ETH_DMAC0CATXBR has a value of 0x0 from the start (buffer address of the transmit descriptor).

 

Best regards,