ETH DMAMR SWR always set, why?

[Peter_TEC]

Hello , 

I have STM32H750x MCU.

 I would like to know why the ETH DMAMR->SWR (software reset bit) is still ALWAYS SET?

I know even the HAL driver is trying to do the SW reset on the ETH DMA and MAC. I know I should have an enabled and stable clock for the HCLK. and i also turn on the clocks for the ETH interface, CLOCK setup for the ETH has been called, using the

 __HAL_RCC_ETH1MAC_CLK_ENABLE();

 __HAL_RCC_ETH1TX_CLK_ENABLE();

 __HAL_RCC_ETH1RX_CLK_ENABLE();

commands are set, and also all the RMII GPIOs are set, and in the SYSCFG register the RMII interface has been selected, still the SWR bit is set, and the only thing I can clear it if I do a:

  __HAL_RCC_ETH1MAC_FORCE_RESET();

but after this I have to again release the forced reset using the

  __HAL_RCC_ETH1MAC_RELEASE_RESET();

command, but still the SWR bit immediately switches back to SET state, so thats why simply the ETH DMA does not start working. 

How can I debug or check why the SWR bit is always ON??

Thanks, Peter

[Piranha]

RMII REF_CLK 50 MHz must also be present and stable. Is it?

[Peter_TEC]

Hello, actually this also the my feeling, it is under investigation. But sofar I think there will be a wrong HW configuration. the LED2/nINTSEL pin of the ETH PHY chip (SMSC LAN8742A) not connected correctly and the ETH PHY is configured not to the REF CLOCK enable but into INTERRUPT mode. even my green LED on the RJ45 connector is constantly ON, even there is no LAN cable plugged into it.

[Peter_TEC]

Hello!

Thanks for the tip. The issue is really was the REF_CLOCK. it was missing. I dont know why this is not documented properly that it has affect on the SWR state.

[DKing.1]

Hi Peter. I'm hoping you'll see notification of this reply. Could I possibly quiz you on the REF_CLOCK solution, that you allude to above. Here, with STM32CubeMX, I've created an LWIP application for our STM32H753IIT6. But I'm likewise seeing HAL_ETH_Init error due to ETH_DMAMR_SWR fail to clear. Our PHY is infact an KSZ8864CNX-RMNUB switch, operating in PHY mode. The code successfully performs MDIO read/write at least. Ping from PC fails though. Have burnt 2 days thus far trying to establish comms. Best regards, David King

[Peter_TEC]

Hello DKing,

Usually if you have the ETH_DMAMR_SWR flag always in set state, means that you do not have a stable reference clock form the PHY. The MDIO communication still can work, since it doesn't relay on the REF_CLOCK. The REF_CLOCK usually an output clock coming from ethernet phy. (Btw. It really depends on the RMII/MII configuration, does your ETH PHY really provides also the output reference clock) This ref.clock is needed by the ETH DMA and ETH peripheral to sample correctly the ethernet frames coming from the phy, and it is not related to the MDIO communication the MDIO has its own MDIO clock.

One more thing, the CubeMX code generation for ETH and LWIP doesn't work immediately you need to also set MPU Caches etc:

see these topics as well:

https://community.st.com/s/question/0D50X00009hobvmSAA/ethernet-communnication-with-stm32h7-nucleo-cubemx-and-keil

https://community.st.com/s/article/FAQ-Ethernet-not-working-on-STM32H7x3

Ping is ICMP! do not forget, you have to also enable ICMP in your TCP/IP stack to support ICMP protocol as well.

[DKing.1]

Hi Peter,

Many thanks for your reply, which I acted on straight away, though have only just now got to replying to. It transpired that our circuit designer, for reasons as yet unclear, opted to include a 3-pin jumper that allowed the PHY TX clock to be disconnected from the MCU, and instead commoned to the PHY RX clock. Changing the jumper from the latter option to the former allowed the ETH_DMAMR_SWR flag to clear and ping to work =) Indeed I had ICMP enabled from the outset to support ping.

My explanation as above is a little simplified. Infact we have *two* MCUs, each with a separate MII connection including said 3-pin jumper, to a single KSZ8864CNX-RMNUB switch:

- Our 'AP' MCU connects to the switch SM3 MAC, operating in PHY mode, with LWIP configured for 192.168.0.1 00-80-E1-00-00-01

- Our 'NP' MCU connects to the switch SM4 MAC, operating in PHY mode, with LWIP configured for 192.168.0.2 00-80-E1-00-00-02

There is a single MDIO connection of course, jumper selectable for AP MCU or NP MCU control. The MCU that successfully test-reads MII register 0 proceeds to soft reset both MACs, at physical address 2 and 3. Probably best if you don't ask why this topology!

The issue I am now having, is that from a PC, I can ping 192.168.0.1, but not 192.168.0.2. The switch P2LED0 pin is unconnected to select SM3 MAC PHY mode. The switch SCONF0+1 pins are pulled down to select SM4 MAC PHY mode. I'm at a loss presently as to why I seemingly have no SM4 MII connectivity. Or am I perhaps missing some fundamental understanding about how a switch works ?! Are you able to shed any light?

Kind regards,

David

[Piranha]

Take a note that Cube/HAL lwIP integration is a broken bloatware. And for H7 it's so broken, that it's basically disfunctional.

https://community.st.com/s/question/0D50X0000C6eNNSSQ2/bug-fixes-stm32h7-ethernet

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