Skip to content

STM32 EMAC: Ethernet driver initialisation fails in DISCO_F769NI #12577

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

Closed
artokin opened this issue Mar 5, 2020 · 14 comments · Fixed by #12686
Closed

STM32 EMAC: Ethernet driver initialisation fails in DISCO_F769NI #12577

artokin opened this issue Mar 5, 2020 · 14 comments · Fixed by #12686

Comments

@artokin
Copy link
Contributor

artokin commented Mar 5, 2020

Description of defect

STM ethernet driver initialisation fails in DISCO_F769NI and therefore the driver can't be used.

The error happens when fix #12567 is placed on top of Mbed OS master. The driver was working before PR #12464 was merged.

The error log "HAL_ETH_Init issue" inficates the problem in the trace output:

[DBG ][core]: Allocate Root Tasklet
[DBG ][6lo ]: P.Init
[DBG ][core]: NS Root task Init
[DBG ][sck ]: Socket Tasklet Generated
[DBG ][mlme]: SW-MAC driver support rf extension 250000 symbol/seconds 4 us symbol time length
[INFO][brro]: NET_IPV6_BOOTSTRAP_AUTONOMOUS
[INFO][app ]: Using EMAC backhaul driver...
[INFO][STE1]: power_up
[INFO][STE1]: PHY Addr 0 AutoNegotiation 1
[DBG ][STE1]: MAC Addr 00:80:e1:2d:00:3e
[INFO][STE1]: ETH buffers : 4 Rx 4 Tx
[ERR ][STE1]: HAL_ETH_Init issue
[ERR ][app ]: Backhaul driver init failed, retval = -3012
[DBG ][brro]: Create Mesh Interface

Target(s) affected by this defect ?

DISCO_F769NI

Toolchain(s) (name and version) displaying this defect ?

GCC_ARM, ARM, IAR

What version of Mbed-os are you using (tag or sha) ?

e71ab0d

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

mbed-cli 1.10.2

How is this defect reproduced ?

  • Clone git@github.com:ARMmbed/nanostack-border-router.git
  • Change Mbed OS to master
  • Cherry-pick PR STM32 EMAC : increase thread size when mbed-trace is enabled #12567 on top of Mbed OS
  • Build nanostack-border-router application for DISCO_F769NI using S2868A1 radio using command: mbed compile -t GCC_ARM -m DISCO_F769NI -j 0 --app-config ./configs/Wisun_Stm_s2lp_RF.json --profile debug
  • Start tracing the application
  • Observe the trace output, the log indicates error in the EMAC driver initialization
@jeromecoutant
Copy link
Collaborator

Hi
I can reproduce the issue only when no ethernet cable is plugged...
No issue when there is one cable.

@jeromecoutant
Copy link
Collaborator

More details when cable is not plugged.

[ERR ][STE1]: HAL_ETH_Init issue

TIMEOUT comes after waiting linked status.

@jeromecoutant
Copy link
Collaborator

Could you try to add in your json config:
"stm32-emac.eth-phy-AutoNegotiation" : "ETH_AUTONEGOTIATION_DISABLE"
?

@ciarmcom
Copy link
Member

ciarmcom commented Mar 9, 2020

@artokin thank you for the update.It appears however that there is still some missing information:

Have you correctly specified which version of Mbed OS you are using (tag or sha)? We cannot automatically identify a release based on what you have provided.

NOTE: If there are fields which are not applicable then please just add 'n/a' or 'None'.This indicates to us that at least all the fields have been considered.

@adbridge
Copy link
Contributor

adbridge commented Mar 9, 2020

@artokin could you please specify either just the sha or a valid release tag for the mbed-os version. The automation cannot parse something like :
'master plus #234455'
Thanks

@artokin
Copy link
Contributor Author

artokin commented Mar 9, 2020

@adbridge sure, it is now pointing to Mbed OS master.

@ciarmcom
Copy link
Member

ciarmcom commented Mar 9, 2020

Internal Jira reference: https://jira.arm.com/browse/MBOTRIAGE-2583

@adbridge
Copy link
Contributor

adbridge commented Mar 9, 2020

Internal Jira reference: https://jira.arm.com/browse/MBOTRIAGE-2583

@artokin Brilliant thanks - the bot has passed it ;-)

@jeromecoutant
Copy link
Collaborator

Could you try to add in your json config:
"stm32-emac.eth-phy-AutoNegotiation" : "ETH_AUTONEGOTIATION_DISABLE"

Did you try this ?
Should we close the issue?

@artokin
Copy link
Contributor Author

artokin commented Mar 11, 2020

Hi @jeromecoutant , I'm sorry that I haven't got time to try it yet.

I would like to see the driver working like it worked before (the driver initialisation was OK even if there was no cable connected. And when the cable was connected later on the application was good to continue its operation).
With existing behaviour the application should make some kind of retry logic to handle special case when application was started without Ethernet cable.

@JojoS62
Copy link
Contributor

JojoS62 commented Mar 11, 2020

I have looked at the sources and see a difference in the behaviour between V2 (for STM32H7 targets) and V1 (all others):
in V2 it is implemented better, the init does only basic settings in the phy chip. After the link is up, the phy speed and duplexmode are set. This is done every time the link was down and is up again.
In V1, the phy init incl. setting speed / mode is done only at ethernet init. A link up and down is also detected, but speed/mode are not changed again. When the cable is not connected at startup, then the init fails and eth will not come up when the cable is plugged in now.
I have tried also autoneg=false, but this works only when the settings at the switch are the same. With switch in auto mode, I got no connection.
So a clean solution seems to be some more work. I can test to use the code for the LAN8742 phy from V2, this logic looks better. When there was so much refactoring, why wasn't the V2 version used for all phy chips? It would be even cleaner to move the phy code into an external hw component that could be used by any target. For ST boards this solution is ok of course, but for custom targets, this tight coupling is unfortunately.
This is my testproject, it uses the non-blocking connection and prints the up/down events:
https://github.com/JojoS62/testTCPServer

@jeromecoutant
Copy link
Collaborator

in V2 it is implemented better

I think this was the goal of v2 :-)
For a short term patch, I think I am going to revert:
c3653c6

@jeromecoutant
Copy link
Collaborator

Does this patch
jeromecoutant@488c9db
is OK for you?

@0xc0170
Copy link
Contributor

0xc0170 commented Mar 24, 2020

PR sent with fix ^^ , please review

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants