STM32N657 ETH DMA TX stuck in Secure-only configuration

[Ricky_Jeon]

Hello ST Support,

I reproduced an ETH TX DMA issue on STM32N6570-DK where the DMA never consumes the TX descriptor.

Environment

- Board: STM32N6570-DK
- Security: TrustZone enabled, Secure-only platform configuration
- PHY: ID1=0x001C, ID2=0xC916, link-up confirmed
- Interface: RGMII, 1G link

Observed behavior

- HAL_ETH_Transmit*() submit succeeds (st=0)
- TX descriptor OWN bit remains 1 (never cleared by DMA)
- TX complete callback/counter never increments
- DMA enters/keeps TBU state
- Key symptom: DMACCATXBR remains 0 (buffer base is never loaded)

Representative logs

- [eth][post-start] dlar=0x3402C1E0 dtpr=0x3402C1E0 rlr=0x00000003 txcr=0x00200001 dmacc=0x00080218 txqomr=0x0007000A
- [tx][path] st=0 own=0->1 catxdr=0x3402C1E0->0x3402C1E0 catxbr=0x00000000->0x00000000 csr=0x00000000->0x00000004
- [tx][stall] own=1 ... catxdr=0x3402C1E0 catxbr=0x00000000 csr=0x00000004 ... dmad=0x00006400 tps0=0x00006000 axr=0
axw=0

What we already tried (same result in all cases)

1. EDSE on/off (txcr=0x10200001 / 0x00200001)
2. DSL forced/unforced (0/64-bit skip)
3. Descriptor/buffer placement changes:
- ETHRAM (0x341F8xxx)
- AXI SRAM (0x3402xxxx, non-cacheable)
4. RIFSC/RISAF adjustments:
- forced RIMC_ATTR secure/privileged attributes
- widened RISAF2/RISAF6 region permissions
5. CH0-only bring-up attempts, CH1 disabled/separated
6. TBU clear + re-kick (rewrite DTPR)
7. Manual single-descriptor ring probe (DTPR=DLAR and DTPR=DLAR+stride)

Additional notes

- RIMC_ATTR sweep over indices 0..12 produced no hit
- RISAF illegal access latches show no meaningful fault for this path
- No meaningful AXI read/write error status (AXRHSTS/AXWHSTS=0)

Questions

1. On STM32N657, is ETH DMA outbound security attribute control actually under RIFSC RIMC_ATTR?
2. What is the exact outbound master index/mapping for ETH DMA?
3. Is there any known limitation/errata for ETH DMA descriptor fetch in Secure-only configurations?
4. Do you have a recommended initialization sequence for the pattern:
CATXBR=0 + TBU + OWN stuck?

[FBL]

Hi @Ricky_Jeon 

Would you attach minimum firmware to reproduce the issue?

[Ricky_Jeon]

Hello ST Support Team,

I’m seeing a persistent ETH DMA TX stall on STM32N6570-DK and would like your help analyzing the root cause.

Repro project (minimal, ETH/FreeRTOS focused):

https://github.com/RickyJeon97/STM32N6570DK_ETH_DMA.git

Issue summary:

- PHY link comes up correctly.
- TX descriptor OWN bit remains set (own=1) and TX does not progress.
- DMA status is stable at csr=0x00000004.
- AXI fault counters remain zero (axr=0, axw=0).

Representative log:

[phy] addr=0 id1=0x001C id2=0xC916
[eth][dsl] forced DSL=0
[eth][txq0] qomr 0x0007000A->0x00070006
[eth][post-start] dlar=0x3402B0C0 dtpr=0x3402B0C0 rlr=0x00000003 txcr=0x00200001 dmacc=0x00000218 txqomr=0x00070006
[phy] link up (addr=0 bmsr=0x79AD)
[tx][stall] own=1 csr=0x00000004 catxdr=0x3402B0C0 catxbr=0x00000000 dlar=0x3402B0C0 dtpr=0x3402B0C0 d0=0x3402C000
d3=0xB000003C dmad=0x00006400 axr=0 axw=0
[focus] txdesc_s=0x3402B0C0 txdesc_ns=0x2402B0C0 txbuf_s=0x3402C000 txbuf_ns=0x2402C000
[tx][tdtA] rlr=0x00000003 stride=0x18 dtpr=0x3402B0C0 catxbr=0x00000000 dmad=0x00006400
[tx][tdtB] rlr=0x00000003 stride=0x18 dtpr=0x3402B108 catxbr=0x00000000 dmad=0x00006400

What I need help with:

1. Is this register/descriptor state indicating a known configuration issue?
2. Are there specific ETH DMA/MTL/MAC settings on STM32N657 that can cause TX OWN to never clear in this state?
3. Any recommended debug checkpoints (registers or sequence) for CH0 TX descriptor fetch/advance?

Thanks in advance for your guidance.

[FBL]

Hi @Ricky_Jeon 

Your project doesn't seem to be similar to the reference projects.

The fastest way to narrow down the root cause is to:

1. Start from the reference example for STM32N657 ETH.
2. Diff your configuration, ETH initialization against it along.

[Ricky_Jeon]

Hi @FBL 

Thanks for the advice.

Where can I find a reference example?

[FBL]

Hi @Ricky_Jeon 

You can find it here.

[Ricky_Jeon]

Hi @FBL 

Thanks for the advice.

It was helpful.