Skip to content
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

STM32 EMAC : add configuration choice and connection check #12464

Merged
merged 6 commits into from
Mar 3, 2020

Conversation

jeromecoutant
Copy link
Collaborator

Summary of changes

Request/question started in https://forums.mbed.com/t/stm32f767-ethernet-with-dp83640/7149

This also fixes #12416

So few corrections are proposed:

  • Add some flexibility and be able to configure locally parameters value depending on chosen PHY
  • Add several check before setting OK init and connection procedures

Impact of changes

Migration actions required

STM32 EMAC is more configurable for each application.
Default setting have been set for the supported ST boards.

Documentation


Pull request type

[x] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[x] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers


@ciarmcom
Copy link
Member

@jeromecoutant, thank you for your changes.
@ARMmbed/mbed-os-ipcore @ARMmbed/mbed-os-maintainers please review.

},
"eth-phy-reset-delay": {
"help" : "Reset process time - Default value: 0.5s as specified in LAN8742A datasheet",
"value" : "5000"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

5000 ms is 5 s, not 0.5 s.

@@ -668,14 +713,18 @@ void STM32_EMAC::phy_task()
uint32_t status;

if (HAL_ETH_ReadPHYRegister(&EthHandle, PHY_BSR, &status) == HAL_OK) {
if (emac_link_state_cb) {
if ((emac_link_state_cb) && (status != 0xFFFF)) {
Copy link
Contributor

@JojoS62 JojoS62 Feb 19, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this does not work on my target with LAN8720, still trying to figure out why.

Edit:
fixed, that was a damned wiring error now. Checking against 0xffff works as intended. Wiring error was a fixed level on MDIO pin, and every phy_read returned 0xffff. This is not detected by the interface.

Comment on lines 298 to 299
EthHandle.Init.Speed = ETH_SPEED_100M;
EthHandle.Init.DuplexMode = ETH_MODE_FULLDUPLEX;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not make this configurable too?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you think it can be useful, I can add this parameter ?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that would be useful for us :)

@jeromecoutant jeromecoutant force-pushed the PR_ETHERNET branch 2 times, most recently from fee61d3 to 8ea4422 Compare February 20, 2020 10:17
@JojoS62
Copy link
Contributor

JojoS62 commented Feb 20, 2020

Another suggestion: a PHY ID can be read from registers 2 and 3. This could be read out and provided in an API or printed in the debug/trace log. When this ID is invalid, a warning can be issued to find a wrong PHY address easier.

"eth-phyaddr": {
"thread-stacksize": {
"help": "Stack size for stm32_emac_thread",
"value": 512
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how about increasing the value automatically when the trace is enabled? I think for an user it is difficult to guess a valid stacksize when it is configurable.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

During my tests, I didn't see any big difference...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the adjustable stacksize come in from this:
#12416 (comment)
usually its a system thread and should have a fixed threadsize. Are there other cases than this special with trace enabled where stacksize can be a problem?

@jeromecoutant
Copy link
Collaborator Author

Another suggestion: a PHY ID can be read from registers 2 and 3.

I don't see any register 2 and 3 in LAN8742a...

@JojoS62
Copy link
Contributor

JojoS62 commented Feb 20, 2020

pls check http://ww1.microchip.com/downloads/en/DeviceDoc/DS_LAN8742_00001989A.pdf
page 58ff. This register exists in LAN8742, 8720 and DP83848 and hopefully all others.

@jeromecoutant
Copy link
Collaborator Author

pls check http://ww1.microchip.com/downloads/en/DeviceDoc/DS_LAN8742_00001989A.pdf
page 58ff. This register exists in LAN8742, 8720 and DP83848 and hopefully all others.

OK, what you call "register 2 and 3" are "PHY Identifier 1 and 2" ? :-)

This could be read out and provided in an API or printed in the debug/trace log

OK to print in the debug log. Here is what I get:

[INFO][STE1]: PHY IDENTIFIER 1 REGISTER 0x7
[INFO][STE1]: PHY IDENTIFIER 2 REGISTER 0xc131

@JojoS62
Copy link
Contributor

JojoS62 commented Feb 20, 2020

Yes! The guys from nxp are also reading the ID:

#define DP83848C_ID 0x20005C90 /**< PHY Identifier - DP83848C */
#define LAN8720_ID 0x0007C0F0 /**< PHY Identifier - LAN8720 */
#define KSZ8041_ID 0x00221510 /**< PHY Identifier - KSZ8041 */

@jeromecoutant
Copy link
Collaborator Author

PHY ID debug log added.

0xc0170
0xc0170 previously approved these changes Feb 24, 2020
@0xc0170
Copy link
Contributor

0xc0170 commented Feb 24, 2020

CI started

@mbed-ci
Copy link

mbed-ci commented Feb 24, 2020

Test run: FAILED

Summary: 3 of 4 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

  • jenkins-ci/mbed-os-ci_build-ARM
  • jenkins-ci/mbed-os-ci_build-GCC_ARM
  • jenkins-ci/mbed-os-ci_build-IAR

@0xc0170
Copy link
Contributor

0xc0170 commented Feb 27, 2020

baremetal example failed,

[Error] stm32f4xx_hal_eth.c@294,40: [Pe020]: identifier "MBED_CONF_STM32_EMAC_ETH_PHY_RESET_DELAY" is undefined
[Error] stm32f4xx_hal_eth.c@369,19: [Pe020]: identifier "MBED_CONF_STM32_EMAC_ETH_PHY_STATUS_REGISTER" is undefined
[Error] stm32f4xx_hal_eth.c@385,19: [Pe020]: identifier "MBED_CONF_STM32_EMAC_ETH_PHY_DUPLEX_STATUS" is undefined
[Error] stm32f4xx_hal_eth.c@396,103: [Pe020]: identifier "MBED_CONF_STM32_EMAC_ETH_PHY_SPEED_STATUS" is undefined
[Error] stm32f4xx_hal_eth.c@849,0: [Pe020]: identifier "MBED_CONF_STM32_EMAC_ETH_RXBUFNB" is undefined

@mergify
Copy link

mergify bot commented Feb 28, 2020

This PR cannot be merged due to conflicts. Please rebase to resolve them.

- PHY default configuration can be changed
  - AutoNegotiation
  - Speed
  - DuplexMode
- PHY register offset can be updated depending on chosen PHY

All unused parameters are cleaned.
@mergify mergify bot dismissed 0xc0170’s stale review March 2, 2020 16:18

Pull request has been modified.

@jeromecoutant
Copy link
Collaborator Author

baremetal example failed,

OK, I am not used yet to check this.
Should be corrected now.

@0xc0170
Copy link
Contributor

0xc0170 commented Mar 2, 2020

CI restarted

@mbed-ci
Copy link

mbed-ci commented Mar 2, 2020

Test run: SUCCESS

Summary: 8 of 8 test jobs passed
Build number : 2
Build artifacts

@0xc0170
Copy link
Contributor

0xc0170 commented Mar 3, 2020

@jeromecoutant Is this ready for integration? It looks like to me it is (ready for merge applied).

@0xc0170
Copy link
Contributor

0xc0170 commented Mar 3, 2020

Received OK! Merging now

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

Successfully merging this pull request may close these issues.

EMACInterface::connect() always succeeds with an incorrect PHY address
7 participants