Ethernet issue after power cycling of STM32H723ZG

ETong.1 · ‎2024-01-17

I'm having the same problem with STM32H723ZG, with our own board, Ethernet can only be connected after using ST link to download the code (either by "debug" or "run"). After power cycle the board, it won't connect anymore, reset button didn't help. I tried your change to uncomment out "#define DATA_IN_D2_SRAM"

and it didn't help either. Checking LWIP echo servo example, it also has "#define DATA_IN_D2_SRAM"

commented out but okay to connect after power up with Nucleo STM32H723ZG Eval board. But running the same

example code on our board, it works after download but not after power up.

I'm using Hal driver FW1.11.1.. How do you make memory dump using Cube programmer? The ST link utility doesn't

work with this H7 chip. Anything else I should check?

Thank you.

Amel NASRI · ‎2024-01-24

Question moved to a new thread. Initially asked in (Solved) I have an ethernet issue after power cycling of H7 Nucleo board.

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

STea · ‎2024-01-24

Hello @ETong.1 ,

This could be due to some miss-configuration of the MPU causing it to fail at run time it seems like the Ethernet is unable to access its DMA buffer descriptors so i suggest you check the configuration of the MPU and then place the descriptors manually in the D2_SRAM this is explained in details in the following article .if you still facing this issue it will be helpful to know about your configuration and changes to the Linker file .

BR

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

ETong.1 · ‎2024-01-24

Hi @STea ,

Thanks for your reply.

What I changed was RMII pins from low speed to very high. After that, right after power cycle the board, pressing reset can get Ethernet connection. Then we made hardware change to add a delay to the reset circuit. Now power cycle the board works too. I'm not totally convinced that this is the root cause. You would think pin speed may affect the connection performance but should still allow connection, right?

Here are the configurations of our system:

Not using RTOS, using lwIP.

Using external crystal 25mhz, not same as Eval board that from STlink, so RCC select HSE Crystal/Ceramic Resonator instead of BYPASS clock source.

CPU set as 550mhz.

MPU setting: flash.ld

/* Specify the memory areas */

MEMORY

{

ITCMRAM (xrw) : ORIGIN = 0x00000000, LENGTH = 64K

DTCMRAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K

FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 1024K

RAM_D1 (xrw) : ORIGIN = 0x24000000, LENGTH = 320K

RAM_D2 (xrw) : ORIGIN = 0x30000000, LENGTH = 32K

RAM_D3 (xrw) : ORIGIN = 0x38000000, LENGTH = 16K

}

Descriptors are in D2_SRAM area

What else I could missing? Any manual changes that I need to make?

STea · ‎2024-01-31

Hello @ETong.1

answering your question "You would think pin speed may affect the connection performance but should still allow connection, right?" yes this is right .

also i think you should try to bypass the delayed reset circuit and see the affect on the behavior because i think this delayed reset can lead to miss-configuration of the PHY interface . this is just a recommendation because after checking your software setup and configuration i think this problem is related to your hardware design . it would help if you could send us a snapshot of your design to analyse it .

BR

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

ETong.1 · ‎2024-01-31

Hi BR,

Here are two changes made in the hardware:

one was PDR_ON signal Pin 143 had two resistors R138 10k to VDD and R139 10k to ground. Change made to remove R139 to ground.

Before

After

2nd change was to add the delay to the RST pin to keep it stay grounded for 68ms upon power up.

Before change:

After change

Let me know what you think. Appreciate your help.

STea · ‎2024-02-01

Hello @ETong.1 ,

can you confirm that the modification to the RST circuit inserted the 68ms you which to have if you can send the snapshot of the scope showing the behavior of the RST ?
why did you remove the resistor connecting the PDR_on to the ground ?is there a practical reason behind this change ?

Best Regards

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

ETong.1 · ‎2024-02-01

Hi @STea ,

1. Here is the scope shot of RST:

On the scope ch1 shows the 5v signal with no delay. Ch2 shows the 3.3v signal which is delayed and used to hold the NRST pin Low for that time. (~68ms theoretical, measured ~80ms).

2. Hardware designer found it from this ST application note:

https://www.st.com/resource/en/application_note/an5419-getting-started-with-stm32h723733-stm32h725735-and-stm32h730-value-line-hardware-development-stmicroelectronics.pdf

For packages embedding the PDR_ON pin, the power supply supervisor is enabled by holding PDR_ON high. Thus, the resistor connecting PDR_ON to ground was removed.

Thanks

STea · ‎2024-02-12

Hello @ETong.1 ,

Do you have any update on the issue that you are facing because it seems like it's not related to software or drivers did you check for resistor values capacitors if there is a solder bridge used on the nucleo board that you are missing in your implementation. i'm looking forward to know the root cause of this problem .

BR

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

STea · ‎2024-02-19

Hello @ETong.1 ,

following up on your issue can you try to pull the NRST-Pin to ground after startup and see the effect on the behavior?

BR

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.