topic TJA1101B + S32k3 not getting reference clock in S32K

TJA1101B + S32k3 not getting reference clock

noobsplzwin — Thu, 25 Apr 2024 03:32:12 GMT

Hello NXP Community,

I'm currently working on a custom board integrating the S32K344 MCU and TJA1101B PHY. I'm using the official NXP lwip_FreeRTOS_s32k344 example project for our development. However, we've encountered an issue where the code blocks the Gmac_Ip_InitDMA module during debugging.

I have followed the setup as per the "LWIP_S32K344 DEMO GUIDE.pdf," which notes the S32K3 EMAC's lack of an RMII reference clock. In our design, we are using an external 25 MHz crystal connected to the REF_CLK of the TJA1101B, with the MII_MODE configuration set to 10 (RMII mode with 50 MHz output on REF_CLK).

I suspect there might be a problem with our clock configuration or the schematic connections between the S32K344 and TJA1101B. I have attached our schematic and pin configuration. Could someone with experience in this setup take a look at our schematic and clock pin configuration to see if there are any steps or configurations we might be missing?

I appreciate any guidance or suggestions.

Thanks,

Connor

Re: TJA1101B + S32k3 not getting reference clock

PetrS — Mon, 29 Apr 2024 08:55:37 GMT

Hi,

seems sentence "we are using an external 25 MHz crystal connected to the REF_CLK of the TJA1101B, with the MII_MODE configuration set to 10 (RMII mode with 50 MHz output on REF_CLK" does not correspond to a TJA1101 schematic. As per pin strapping a reverse MII mode is selected and PHY is clocked from 25MHz external crystal connected to XI/XO pins.

BR, Petr

Re: TJA1101B + S32k3 not getting reference clock

noobsplzwin — Mon, 29 Apr 2024 13:54:21 GMT

Hi Petr,

Thanks for the response and sorry for the confusion. The config on the schematic is only the init setup. On my board, I moved 10k from R436 to R437, which should now be RMII mode with 50 MHz output on REF_CLK if my understanding is correct.

Re: TJA1101B + S32k3 not getting reference clock

PetrS — Tue, 30 Apr 2024 10:29:21 GMT

Hi,

yes, with that config you have selected RMII mode with 50 MHz output on REF_CLK. In that case below RMII connection between PHY and MAC applies (taken from tja1101B DS and S32K3 HW guide)...

Seems REF_CLK connection you have is not correct.

Moreover check the RMII EMAC clocking configurations. Not only the 50MHz external RMII reference clocking, but also the clocking multiplexer 7/8/9 for EMAC Rx/Tx/Ts clocking:

Even though it works at RMII mode, the EMAC internal logic still need 25MHz clock which shall be 1/2 divided from external RMII reference clock.

BR, Petr

Re: TJA1101B + S32k3 not getting reference clock

noobsplzwin — Wed, 01 May 2024 14:37:00 GMT

Hi Petr,

I appreciate the guidance you've provided. After re-evaluating the board setup, I realized it was designed to operate in MII mode rather than RMII. Following your suggestions, I adjusted the pin strapping and confirmed a correct 50 MHz clock signal on TXC and RXC pins using an oscilloscope. However, one issue I noticed is that the strength of Tx Clk(+100mV) is significantly weaker than Rx Clk. Is this expected?

RXC

TXC

Also, according to the .mex file's Routing Details, the Lwip_FreeRTOS_s32k344 demo project I am working on seems to be configured only for RMII mode. The project doesn’t appear to check the PHY's Configuration Register 1 (register 18) bit 9:8, which should indicate the PHY’s((TJA1101B)) current operating mode.

Can you help confirm if this demo project is indeed set up solely for RMII? If it's possible to modify it for MII, what changes should I consider? Besides updating the pin configurations under Routing Details, are specific adjustments required in the Peripherals settings in the .mex file, such as the GMAC or TCP/IP stack configurations?

I have a feeling that I'm nearing the completion of this project and hoping this post is the last major hurdle. Thanks for your help in advance!

Best Regards,

Connor

Re: TJA1101B + S32k3 not getting reference clock

bryan_brauchler — Wed, 01 May 2024 16:50:32 GMT

Hi Conner,

The LwIP example included with the S32K3 RTD is configured for RMII.

This project can be modified - You must configure additional pins for MII, (TXD[2-3], RXD[2-3], RXC, optionally RX/TX_ER, CRS, COL) adjust the input clock (25 vs 50MHz with RMII). Note that the internal frequency should still be 25MHz for the EMAC peripheral. and change the mode within the GMAC driver.

Finally, in some versions of the project LwIP you will have to remove the DCM configuration in device_init() that configures RMII clocking within EMAC:

The scope captures look to still be in RMII mode, as the clock frequency generated on both TXC and RXC should be 25MHz in MII mode. RMII only generates 50MHz on REF_CLK (RXC pin)

Best,

Bryan

Re: TJA1101B + S32k3 not getting reference clock

noobsplzwin — Wed, 15 May 2024 23:24:04 GMT

Hi Bryan,

Thanks for your previous suggestion. I implemented it and now have MDIO communication working with the TJA running in MII mode. However, I'm encountering issues with the TCP/IP main thread.

In the attached screenshot, I can see the following problems in TCPIP.c:

When I run the code, it halts at prvCheckTasksWaitingTermination and doesn't reach the while(1) main loop.
If I set a breakpoint at line 135 and then step over, I can reach the while(1) loop and receive a TCP/IP message with the message type TCPIP_MSG_CALLBACK. However, resuming execution causes the code to halt at prvCheckTasksWaitingTermination again.

I've reviewed all the exceptional cases under src, but I can't find anything that terminates the main TCP/IP server task. I'm unsure RTOS would be ideal in this demo project.

Additionally, I'm trying to understand the message I received from TCPIP_MSG_CALLBACK. The data structure is quite confusing. The IPv4 address I received is 541149954, which converts to 32.65.75.2. This doesn't seem to correspond to any known IPv4 address.

Could you please provide some guidance on these issues? Any documentation explaining the TCP/IP message structure would also be helpful. Sorry for the continuous questions, and thanks for all the great help from the NXP team.

Best regards,
Connor