-
Notifications
You must be signed in to change notification settings - Fork 6.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Network connection unreliable on nucleo_f767zi #77794
Comments
Updated bug report after it turned out that Zephyr |
@jkrautmacher can you please confirm that ? |
I would be glad to help but unsure what to confirm. As far as I understood the current theory is that the power supply of the PHY on If this is correct my next debugging step would be to connect an oscilloscope to the supply voltage of the PHY and observe it during init. That together with a debug GPIO from the kernel code which toggles right before and after Ethernet init should validate this theory or not. The next step would be to either fix the hardware design or to add a workaround to the Zephyr kernel (longer delays or similar). I am lacking two things to verify the theory:
Is there maybe more public information about the board than in UM1974 Rev 10 I overlooked? The oscilloscope situation I could maybe improve but it would likely be way faster if you could do that at ST if this is an option. |
Describe the bug
While working on a quite minimal Zephyr firmware for the
nucleo_f767zi
board I noticed that the network connection is unreliable. As shown below this is reproducible with thenet/telnet
sample.The bug can be noticed by the following indicators:
stm_eth
thread has significantly lower stack usage (see shell output ofkernel stacks
)The bug appears after roughly 40 % of the boot processes. It was so far not observed that network communication breaks later if it was operational directly after booting the board.
To Reproduce
Steps to reproduce the behavior:
nucleo_f767zi
board with an Ethernet cable to a Linux PC192.0.2.2/24
on the PCst-info
tool (see e.g. source repo)samples/net/telnet
as described in the Getting Started GuideExpected behavior
It is expected that the used script reports 100 % success rate.
Impact
This bug is a showstopper. A firmware with such an unreliable network connection is useless.
Logs and console output
The script summarizes a test with 100 iterations on my setup with:
Success rate is 44 % (44 ok and 56 failed)
forzephyr v3.7.0
Success rate is 39 % (39 ok and 61 failed)
forzephyr v3.6.0
Environment (please complete the following information):
0.16.5
v3.7.0
andv3.6.0
The text was updated successfully, but these errors were encountered: