S32K344 RMII Problem with GMAC driver

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

S32K344 RMII Problem with GMAC driver

Jump to solution
1,372 Views
MehmetFatih
Contributor I

Hello,

I am working with the S32K344 MCU and using the LAN8710A Ethernet PHY in RMII mode. My goal is to transmit data from the MCU to a PC, but I am facing issues in the process.

Setup and Observations:

  • I can access the LAN8710A registers via MDIO.
  • I have verified that the STRAP pins are correctly set for RMII mode.
  • The GMac_IP_Internal_Loopback example code runs successfully.
  • When I disable MAC_CONFIG_LOOPBACK in the EthCtrlConfigMac section of the GMac driver configuration and attempt to send data to the PC, I receive nothing.
  • When I enable Far Loopback mode on the LAN8710A, it correctly echoes back the data sent from the PC.
  • Initially, after disabling internal loopback, I observed corrupted data on the PC. Later, I found that the EMAC_MII_RMII_TX_CLK pin was floating and was not connected to a 50 MHz clock signal.
  • Even with the floating TX_CLK, I was able to receive corrupted data. However, after properly connecting the TX_CLK to 50 MHz, I can no longer receive any data at all.
  • One unusual observation: When TX_CLK was not connected, I could still receive some form of data, though it was corrupted.
    • For example, if I sent a packet filled with 0xFF, I would receive only 0xFF values.
    • If I sent a packet filled with 0xF0, I received a mix of 0x30 and other byte values.

Questions:

  1. What could be causing the transmission failure after properly connecting the 50 MHz TX_CLK?
  2. Is there any additional configuration required in the GMAC driver to enable external transmission?
  3. Are there any known issues or errata related to S32K344 + LAN8710A RMII mode that could explain this behavior?
  4. How was I able to receive any data at all when TX_CLK was not connected? Even though it was corrupted, it seemed to maintain a pattern related to the original data. What could be the explanation for this behavior?

Any insights or suggestions would be greatly appreciated.

Thank you!

0 Kudos
Reply
1 Solution
1,319 Views
MehmetFatih
Contributor I

Hi Julián,

Thank you for your response. I wanted to share my findings in case anyone else encounters a similar issue.

After further debugging, I was able to resolve the problem by making two key modifications:

  1. Before calling Siul2_Port_Ip_Init, I applied the following configuration:

    IP_DCM_GPR->DCMRWF1 = (IP_DCM_GPR->DCMRWF1 & ~DCM_GPR_DCMRWF1_EMAC_CONF_SEL_MASK) | DCM_GPR_DCMRWF1_EMAC_CONF_SEL(2U);
  2. In the clock configuration, I set the dividers for EMAC_TX_CLK and EMAC_RX_CLK to 2, reducing their frequencies to 25 MHz.

After applying these changes, data transmission started working correctly.

For reference, the corrupted data issue observed when TX_CLK was not connected remains an interesting behavior, but after properly setting up the reference clocks and configuration registers, the system now operates as expected.

I hope this helps others who might face similar issues.

Best regards,
Mehmet Fatih

View solution in original post

2 Replies
1,320 Views
MehmetFatih
Contributor I

Hi Julián,

Thank you for your response. I wanted to share my findings in case anyone else encounters a similar issue.

After further debugging, I was able to resolve the problem by making two key modifications:

  1. Before calling Siul2_Port_Ip_Init, I applied the following configuration:

    IP_DCM_GPR->DCMRWF1 = (IP_DCM_GPR->DCMRWF1 & ~DCM_GPR_DCMRWF1_EMAC_CONF_SEL_MASK) | DCM_GPR_DCMRWF1_EMAC_CONF_SEL(2U);
  2. In the clock configuration, I set the dividers for EMAC_TX_CLK and EMAC_RX_CLK to 2, reducing their frequencies to 25 MHz.

After applying these changes, data transmission started working correctly.

For reference, the corrupted data issue observed when TX_CLK was not connected remains an interesting behavior, but after properly setting up the reference clocks and configuration registers, the system now operates as expected.

I hope this helps others who might face similar issues.

Best regards,
Mehmet Fatih

1,352 Views
Julián_AragónM
NXP TechSupport
NXP TechSupport

Hi @MehmetFatih,

Since the LAN8710A is a third-party device, support is limited, because of this, there is no S32K344 + LAN8710A erratas or documentation.

I'm not sure what the corrupted data may indicate, since transmission was made without a clock, but are you able to analyze the signal with an oscilloscope or logic analyzer to see if the frame is being sent/received correctly after connecting the 50Mhz?

in order to configure transmission and reception, you must also configure the interrupt driver, please refer to this community post: Solved: GMAC of S32K344 Callbackfun - NXP Community.

Could you also share the connection for the reference clock?

Best regards,
Julián

0 Kudos
Reply
%3CLINGO-SUB%20id%3D%22lingo-sub-2036219%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3ES32K344%20RMII%20Problem%20with%20GMAC%20driver%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2036219%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3EHello%2C%3C%2FP%3E%3CP%3EI%20am%20working%20with%20the%20%3CSTRONG%3ES32K344%3C%2FSTRONG%3E%20MCU%20and%20using%20the%20%3CSTRONG%3ELAN8710A%3C%2FSTRONG%3E%20Ethernet%20PHY%20in%20%3CSTRONG%3ERMII%20mode%3C%2FSTRONG%3E.%20My%20goal%20is%20to%20transmit%20data%20from%20the%20MCU%20to%20a%20PC%2C%20but%20I%20am%20facing%20issues%20in%20the%20process.%3C%2FP%3E%3CH3%20id%3D%22toc-hId-1943375354%22%20id%3D%22toc-hId-2001469010%22%3E%3CSTRONG%3ESetup%20and%20Observations%3A%3C%2FSTRONG%3E%3C%2FH3%3E%3CUL%3E%3CLI%3EI%20can%20access%20the%20%3CSTRONG%3ELAN8710A%20registers%20via%20MDIO%3C%2FSTRONG%3E.%3C%2FLI%3E%3CLI%3EI%20have%20verified%20that%20the%20%3CSTRONG%3ESTRAP%20pins%20are%20correctly%20set%20for%20RMII%20mode%3C%2FSTRONG%3E.%3C%2FLI%3E%3CLI%3EThe%20%3CSTRONG%3EGMac_IP_Internal_Loopback%3C%2FSTRONG%3E%20example%20code%20runs%20successfully.%3C%2FLI%3E%3CLI%3EWhen%20I%20disable%20%3CSTRONG%3EMAC_CONFIG_LOOPBACK%3C%2FSTRONG%3E%20in%20the%20%3CSTRONG%3EEthCtrlConfigMac%3C%2FSTRONG%3E%20section%20of%20the%20GMac%20driver%20configuration%20and%20attempt%20to%20send%20data%20to%20the%20PC%2C%20I%20receive%20nothing.%3C%2FLI%3E%3CLI%3EWhen%20I%20enable%20%3CSTRONG%3EFar%20Loopback%3C%2FSTRONG%3E%20mode%20on%20the%20%3CSTRONG%3ELAN8710A%3C%2FSTRONG%3E%2C%20it%20correctly%20echoes%20back%20the%20data%20sent%20from%20the%20PC.%3C%2FLI%3E%3CLI%3EInitially%2C%20after%20disabling%20internal%20loopback%2C%20I%20observed%20corrupted%20data%20on%20the%20PC.%20Later%2C%20I%20found%20that%20the%20%3CSTRONG%3EEMAC_MII_RMII_TX_CLK%20pin%20was%20floating%3C%2FSTRONG%3E%20and%20was%20not%20connected%20to%20a%20%3CSTRONG%3E50%20MHz%20clock%20signal%3C%2FSTRONG%3E.%3C%2FLI%3E%3CLI%3EEven%20with%20the%20floating%20TX_CLK%2C%20I%20was%20able%20to%20receive%20%3CSTRONG%3Ecorrupted%20data%3C%2FSTRONG%3E.%20However%2C%20after%20properly%20connecting%20the%20TX_CLK%20to%2050%20MHz%2C%20I%20can%20no%20longer%20receive%20any%20data%20at%20all.%3C%2FLI%3E%3CLI%3EOne%20unusual%20observation%3A%20%3CSTRONG%3EWhen%20TX_CLK%20was%20not%20connected%2C%20I%20could%20still%20receive%20some%20form%20of%20data%2C%20though%20it%20was%20corrupted.%3C%2FSTRONG%3E%3CUL%3E%3CLI%3EFor%20example%2C%20if%20I%20sent%20a%20packet%20filled%20with%20%3CSTRONG%3E0xFF%3C%2FSTRONG%3E%2C%20I%20would%20receive%20only%20%3CSTRONG%3E0xFF%3C%2FSTRONG%3E%20values.%3C%2FLI%3E%3CLI%3EIf%20I%20sent%20a%20packet%20filled%20with%20%3CSTRONG%3E0xF0%3C%2FSTRONG%3E%2C%20I%20received%20a%20mix%20of%20%3CSTRONG%3E0x30%20and%20other%20byte%20values%3C%2FSTRONG%3E.%3C%2FLI%3E%3C%2FUL%3E%3C%2FLI%3E%3C%2FUL%3E%3CH3%20id%3D%22toc-hId-135920891%22%20id%3D%22toc-hId-194014547%22%3E%3CSTRONG%3EQuestions%3A%3C%2FSTRONG%3E%3C%2FH3%3E%3COL%3E%3CLI%3EWhat%20could%20be%20causing%20the%20transmission%20failure%20after%20properly%20connecting%20the%20%3CSTRONG%3E50%20MHz%20TX_CLK%3C%2FSTRONG%3E%3F%3C%2FLI%3E%3CLI%3EIs%20there%20any%20additional%20configuration%20required%20in%20the%20%3CSTRONG%3EGMAC%20driver%3C%2FSTRONG%3E%20to%20enable%20external%20transmission%3F%3C%2FLI%3E%3CLI%3EAre%20there%20any%20known%20issues%20or%20errata%20related%20to%20%3CSTRONG%3ES32K344%20%2B%20LAN8710A%20RMII%20mode%3C%2FSTRONG%3E%20that%20could%20explain%20this%20behavior%3F%3C%2FLI%3E%3CLI%3E%3CSTRONG%3EHow%20was%20I%20able%20to%20receive%20any%20data%20at%20all%20when%20TX_CLK%20was%20not%20connected%3F%3C%2FSTRONG%3E%20Even%20though%20it%20was%20corrupted%2C%20it%20seemed%20to%20maintain%20a%20pattern%20related%20to%20the%20original%20data.%20What%20could%20be%20the%20explanation%20for%20this%20behavior%3F%3C%2FLI%3E%3C%2FOL%3E%3CP%3EAny%20insights%20or%20suggestions%20would%20be%20greatly%20appreciated.%3C%2FP%3E%3CP%3EThank%20you!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2036471%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3ERe%3A%20S32K344%20RMII%20Problem%20with%20GMAC%20driver%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2036471%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3EHi%20Juli%C3%A1n%2C%3C%2FP%3E%3CP%3EThank%20you%20for%20your%20response.%20I%20wanted%20to%20share%20my%20findings%20in%20case%20anyone%20else%20encounters%20a%20similar%20issue.%3C%2FP%3E%3CP%3EAfter%20further%20debugging%2C%20I%20was%20able%20to%20resolve%20the%20problem%20by%20making%20two%20key%20modifications%3A%3C%2FP%3E%3COL%3E%3CLI%3E%3CSTRONG%3EBefore%20calling%20Siul2_Port_Ip_Init%2C%20I%20applied%20the%20following%20configuration%3A%3C%2FSTRONG%3E%3CDIV%20class%3D%22%22%3E%3CDIV%20class%3D%22%22%3E%3CBR%20%2F%3EIP_DCM_GPR-%26gt%3BDCMRWF1%20%3D%20(IP_DCM_GPR-%26gt%3BDCMRWF1%20%26amp%3B%20~DCM_GPR_DCMRWF1_EMAC_CONF_SEL_MASK)%20%7C%20DCM_GPR_DCMRWF1_EMAC_CONF_SEL(%3CSPAN%20class%3D%22%22%3E2U%3C%2FSPAN%3E)%3B%3C%2FDIV%3E%3C%2FDIV%3E%3C%2FLI%3E%3CLI%3E%3CSTRONG%3EIn%20the%20clock%20configuration%2C%20I%20set%20the%20dividers%20for%20EMAC_TX_CLK%20and%20EMAC_RX_CLK%20to%202%2C%20reducing%20their%20frequencies%20to%2025%20MHz.%3C%2FSTRONG%3E%3C%2FLI%3E%3C%2FOL%3E%3CP%3EAfter%20applying%20these%20changes%2C%20data%20transmission%20started%20working%20correctly.%3C%2FP%3E%3CP%3EFor%20reference%2C%20the%20corrupted%20data%20issue%20observed%20when%20TX_CLK%20was%20not%20connected%20remains%20an%20interesting%20behavior%2C%20but%20after%20properly%20setting%20up%20the%20reference%20clocks%20and%20configuration%20registers%2C%20the%20system%20now%20operates%20as%20expected.%3C%2FP%3E%3CP%3EI%20hope%20this%20helps%20others%20who%20might%20face%20similar%20issues.%3C%2FP%3E%3CP%3EBest%20regards%2C%3CBR%20%2F%3EMehmet%20Fatih%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2036334%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3ERe%3A%20S32K344%20RMII%20Problem%20with%20GMAC%20driver%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2036334%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3EHi%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fcommunity.nxp.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F244483%22%20target%3D%22_blank%22%3E%40MehmetFatih%3C%2FA%3E%2C%3C%2FP%3E%0A%3CP%3ESince%20the%26nbsp%3BLAN8710A%20is%20a%20third-party%20device%2C%20support%20is%20limited%2C%20because%20of%20this%2C%20there%20is%20no%26nbsp%3B%3CSTRONG%3ES32K344%20%2B%20LAN8710A%26nbsp%3B%3C%2FSTRONG%3Eerratas%20or%20documentation.%3C%2FP%3E%0A%3CP%3EI'm%20not%20sure%20what%20the%20corrupted%20data%20may%20indicate%2C%20since%20transmission%20was%20made%20without%20a%20clock%2C%20but%20are%20you%20able%20to%20analyze%20the%20signal%20with%20an%20oscilloscope%20or%20logic%20analyzer%20to%20see%20if%20the%20frame%20is%20being%20sent%2Freceived%20correctly%20after%20connecting%20the%2050Mhz%3F%3C%2FP%3E%0A%3CP%3Ein%20order%20to%20configure%20transmission%20and%20reception%2C%20you%20must%20also%20configure%20the%20interrupt%20driver%2C%20please%20refer%20to%20this%20community%20post%3A%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fcommunity.nxp.com%2Ft5%2FS32K%2FGMAC-of-S32K344-Callbackfun%2Ftd-p%2F1714671%22%20target%3D%22_blank%22%3ESolved%3A%20GMAC%20of%20S32K344%20Callbackfun%20-%20NXP%20Community%3C%2FA%3E.%3C%2FP%3E%0A%3CP%3ECould%20you%20also%20share%20the%20connection%20for%20the%20reference%20clock%3F%3C%2FP%3E%0A%3CP%3EBest%20regards%2C%3CBR%20%2F%3EJuli%C3%A1n%3C%2FP%3E%3C%2FLINGO-BODY%3E