MCU-PLUS-SDK-AM243X: Ethernet Phy boottime

Hi Fabian,

We have started looking into the threads let me try to get back with my findings by Friday

Fabian,

Can you please help me with following details:

1. Which MCU SDK version are you using

2. Which version of profinet example are you using(Is is Kunbus Profinet example or your own Profinet stack)

3. Also are you using MDIO manual mode?

Fabian Sorkalla said:

houldn't this 50ms be handled at the PRU level? Atleast we should get on application level an error code which indicates something like: "PRU not ready" or/ and "EHTPHY not ready

No, PHY handling is done via Application, It is left at application descretion how they want to take care of phy handling. Yes if there is such requirement then it should be handled in application.

Fabian Sorkalla said:

I think the reset Pin of the ETH-Phy is also driven by PRU so this should be handled by the SDK.

It may be connected to PRU but driving of the pin is again done by application.

Fabian Sorkalla said:

Is there already a function to check if PRU and ETH-Phy is booted completly? 

Same as before, this has to be handled by application since PRU code is not PHY dependent.

Fabian Sorkalla said:

But atleast I think the "command-function" of the ETH-Phy driver should return a error code as mentioned before.

Eth PHy function does have error code for failed transaction

/resized-image/__size/320x240/__key/communityserver-discussions-components-files/908/pastedimage1678364072146v1.png

Now coming to the error signature Can you please elaborate if you see any error in your application

Fabian Sorkalla said:

In some cirumstances It could happend that your system at boottime hangs. Call-Stack looks like this:

I did not get this completly, Can you please elaborate and 

Fabian Sorkalla said:

This brings the hole system into a non-responsive state, where it just idles in the above call-stack.

Do you see this state consistently and while you do run iterations do you power reset the board, beacuse all industrial application requires power reset on restart.

BR

Nilabh A.,

Hi Nilabh,

RST_N of Eth Phy is wired to Sitara to GPIO

I think we then need to Reset Eth Phy in software to be sure Eth Phy is in a correct state. 

On bootup I think we need to do something like this:

Configure this Pin as output. drive it low for atleast 25µs drive it high and wait 50ms till Phy boot is complete. 

Am I correct on this?

BR

Fabian

Hi Fabian, this practice can work. BUr I would like to confirm the point I had mentioned before:

Nilabh Anand said:

Do you see this state consistently and while you do run iterations do you power reset the board, beacuse all industrial application requires power reset on restart.

Can you please confirm it?

Hi Nilabh,

we see this during "real" Power down and on. We do some Power-Supply "Jitter" test in QA.

We power the device on and after short of time cutting power again (we do this several times in a row).

After like 5 "pulses" we have a look if the device boots up correctly 

Hi Fabian,

So the issue appears during the QA test, It seems some how it is dependent on the power cycle timings. This may be dependent on board characteristics(like capacitor and time it will take for discharge) We need to check with expert on Hw side. Please expect a reply from him soon.

Can you also please elaborate how power jitter testing is being done here?

BR

Nilabh A.

Hi Nilabh,

"jitter power supply" test is done as followed:

1. Switch ON main-supply of PCBA

2. wait 100ms 

3. Switch OFF main-supply of PCBA 

4. wait 100ms

5. Repeat Steps 1. to 4. four times

6. Try to "ping" the pcba over Ethernet

7. If PCBA could be pinged goto step 1 again

This is done over hours of testing.

BR

Fabian

Hey Fabian,

Is a discrete power solution being used or a PMIC?

Can you provide schematics for Power Distribution Network of PCBA? 

I agree with your earlier statement that the application code should be in charge of resetting the Ethernet PHY once the AM243x device has booted and all power/clock signals are stable.

Best Regards,

Zackary Fleenor

Hi Zack & Nilabh,

okay I think then we need to do a reset on application level. 

But what are the recomendations on your side for doing this reset? Should we always wait 50ms and then released the reset or 
is there something like a alive register which we can poll?

Thanks 

Fabian

hello Zack & Nilabh,

colleague of Fabian here.

I noticed in the TRM there is a MDIO_ALIVE_REG register. I just checked this one and it seems it represents the correct values:

which would mean ethphys for address 0 and 2 are active. which are the correct addresses.

But I do not see this register used in any driver.

If I follow the description of it:
"Each of the 32 bits of this register is set if the most recent access to the PHY with address corresponding to the register bit number was acknowledged by the PHY, the bit is reset if the PHY fails to acknowledge the access. Both the user and polling accesses to a PHY will cause the corresponding alive bit to be updated. The alive bits are intended to be used to give an indication of the presence or not of the PHY with the corresponding address. Writing a 1 to any bit will clear it, writing a 0 has no effect."

This bit should tell us if the PHY is available, but only after a polling access will update the bit. Since we experienced this hung up in the MDIO-access I am not sure what is meant with a "polling access to the PHY". Would a continous PhyRegRead be a polling access? so we may just read any register of the phy continuously and check back the register to be sure the PHY is alive?

Or how would a good handling look alike?

The thing is we cannot insert a 50 ms wait in our startup, since our devices need to power up fast. This would maybe lead to this situation:
Sitara and EthPhy are powered up at the same time. Fw starts up and takes maybe 20 ms to come to the point starting the Eth-Phy-driver. a sleep then would lead to an overall 70 ms-time instead of the only needed 50 ms.

So checking a register whether the phy is alive or not would be way more performant. Additionally the question is, if this register works, if there is still a need for pulling the reset-pin of the EthPhy. I would guess that it would be more stable then especially when bouncing the power supply and according to the data sheet this reset should only take 2 ms instead of 50, so it's ok for us.

So my suggesstion would be:
1. powering up Sitara and EthPhy at the same time
2. when creating the EthPhyDriver checking the MDIO-alive-register for the corresponding EthPhy in maybe a 1 ms-intervall by also polling any register of the Phy.
3. (if still needed) if Phy is alive, reset via RST_N-Pin by pulling it to low for at least 25µs, wait 2 ms (3ms to ensure no timing issues) and proceed with the fw.

Is this a suitable approach that would work?

Best regards

Felix