S32K中的主题 Re: S32K344 RMII Debugging

S32K344 RMII Debugging

jay12 — Thu, 14 Mar 2024 15:43:51 GMT

Hi,

I'm debugging an issue with the S32K344 on the RMII interface on a custom board.

The S32K344 is setup as the MAC and is connected to a switch port that is acting like a PHY.

The switch port is providing the 50MHz reference clock to the S32K344.

There seems to be some kind of data corruption when the data goes through the MAC layer on the S32K3.

Probing the RMII lines on the board and using a logic analyzer, I'm able to reconstruct a valid ARP packet coming out of the switch and into the S32K344. However, the data the S32K344 the data seems to receive is invalid. Since the data on the wire is okay, I'm thinking the corruption is either happening when the S32K344 is sampling the data or in the settings on the MAC.

On the S32K344 TX side of things the data that comes out on the wire is corrupted .

If I turn off CRC checking on the switch, the corrupted packet can be seen via wireshark. If I turn off CRC checking on the S32K344, the corrupted packet is able to make it to the application.

We used a similar code setup on the MR-CANHUBK344 and were successful.

Any help or knobs to turn on the S32K344 side would be appreciated!

Thank you!

Re: S32K344 RMII Debugging

PetrS — Mon, 18 Mar 2024 11:45:13 GMT

Hi,

maybe you can referr to S32K3-T-BOX board (https://www.nxp.com/design/design-center/designs/s32k3-automotive-telematics-box-t-box-reference-design-board:S32K3-T-BOX), which has SJA1110 connected to S32K3 using RMII as well. You can check its schematic and available example projects.

BR, Petr

Re: S32K344 RMII Debugging

jay12 — Tue, 19 Mar 2024 03:59:04 GMT

Thanks for the link.

For pin mapping we did:

PTC0: RXD0

PTC1: RXD1

PTC2: TXD0

PTD7: TXD1

PTC14: RX_ER

PTC15: RX_DV

PTD11: TX_CLK

PTD12: TX_EN

When the S32K3 sends out an ARP, the data on the wire is odd. Here is a scope screenshot of what the beginning of the ethernet frame looks like (preamble, SFD, destination MAC):

Channel 1: TXD0

Channel 2: TXD1

The destination MAC address is supposed to be FF:FF:FF:FF:FF:FF as it's a broadcast. However, looking at the wire we see: FD:FF:FF:FF:FF:FF.

Is there a way to look at the ethernet frame before it's transmitted by the MAC? Could there be something weird happening with DMA with the descriptors? Any advice on debugging this would be appreciated.

Thank you,

Jay Fetter

Re: S32K344 RMII Debugging

Siyan — Tue, 19 Mar 2024 07:51:40 GMT

I have solved a similar problem by reconfiguring the MCU clock after the switch clock can be provided stably to the S32K. Maybe you should try on your side and see if it works.

Re: S32K344 RMII Debugging

jay12 — Tue, 19 Mar 2024 20:08:30 GMT

I tried adding a long delay between the switch initialization and the Clock_Ip_Init function call and I'm still seeing this issue.

Some more example packets:

Re: S32K344 RMII Debugging

PetrS — Thu, 21 Mar 2024 09:34:24 GMT

Hi,

try to increase slew rate/drive strength for TX signals in Pins tool as well.

BR, Petr

Re: S32K344 RMII Debugging

jay12 — Thu, 21 Mar 2024 15:10:18 GMT

Tried that as well.

Is there any way to view the transmit queue in the MAC layer? Any way to observe what is getting pushed out the wire?

I was looking at the MTL registers and trying to figure out how to use the debug register (C08h, MTL_DBG_CTL), but was a bit confused.

Re: S32K344 RMII Debugging

jay12 — Thu, 21 Mar 2024 21:36:37 GMT

Comparing the pins between the T-Box and our board:

Function	Our Board	T-Box
RXD0	PTC0	PTC0
RXD1	PTC1	PTC1
RX_ER	PTC14	PTC14
RX_DV	PTC15	PTC17
TXD0	PTC2	PTC2
TXD1	PTD7	PTD7
TX_EN	PTD12	PTD12
TX_CLK	PTD11	PTD11

Only difference is RX_DV. Looking at the pinmux, both PTC15 and PTC17 can be: EMAC_MII_RMII_RX_DV.

Have there been any software driver updates in recent months that could affect the EMAC?

Re: S32K344 RMII Debugging

Daniel_Wax — Fri, 22 Mar 2024 16:53:17 GMT

post the studio project that sets up the ethernet

Re: S32K344 RMII Debugging

jay12 — Sat, 23 Mar 2024 13:59:27 GMT

I'll have to check per company policy on sharing source code.

What files would be most important to look at since individual files may be easier?

Re: S32K344 RMII Debugging

Daniel_Wax — Tue, 26 Mar 2024 01:31:10 GMT

The ethernet interface setup and init may be useful

Ill check out the ref manual for TX packet content. I dont think there is a feature like that. BTW have you checked out loopback just to see if thats clean? So you want to see TX for loopback verification?

Re: S32K344 RMII Debugging

jay12 — Tue, 26 Mar 2024 13:26:49 GMT

Uploaded project to a private case.

I don't think you can do internal loopback in RMII mode. We did an experiment where we allowed to switch to route packets sent on the S32K3's port back to itself (i.e. S32K3 -> Switch Port X -> S32K3) and the data was still malformed.

What would be the lowest memory layer that we could observe the packet? Would it be in the Gmac_Ip_SendFrame function? I'm just confused on how to explain the behavior we're seeing.

There is a difference in the S32K3 package between the MR-CANHUB (QFP) and our board (BGA).

Re: S32K344 RMII Debugging

Daniel_Wax — Tue, 26 Mar 2024 22:09:33 GMT

~~Im not sure where this private case is located.~~

I found it in nxp.support.com. Ill start looking at it. So with the project you uploaded the same corruption happens?

I was talking about this loopback

I now see we also call EMAC GMAC from the driver setup standpoint

GMAC registers are not applicable ... only EMAC 100Mbit only no Gigabit

There are some registers that may be useful. I See others as well

Package pinout differences are indicated in the ref manual. Its the same die if both part numbers are S32K344

@JD_Wilson

Re: S32K344 RMII Debugging

Daniel_Wax — Tue, 26 Mar 2024 22:30:11 GMT

I was looking at our eval board where we connect to one of our phys that supplies the clock for RX and even though its an external clock we still setup the RX clock to be enabled in the clock setup.

You project does not enable this RX clock. maybe you can try that?

Re: S32K344 RMII Debugging

jay12 — Thu, 28 Mar 2024 19:49:31 GMT

Some updates, we are definitely seeing extra nibbles in our RMII TX data.

However, even with the data on the wire being corrupted, we sometimes see a CRC that would match the packet that was intended to be sent out. Which would imply to me that the correct packet is reaching that MAC.

Here is a graph showing the extra clock cycles we see based on the packet size.

For example, for a 60Byte ARP packet, we are expecting to see 72Bytes on the wire (7B Preamble + 1B SFD + 4B CRC). 72Bytes * 20ns/(di-bit) * 4 (di-bit) / Byte = 5760ns.

However, when we measure on the wire we see 5980 ns for the frame. This was measured using the DV signal.

We've tried looking at the registers, comparing the clocks, power supplies, not sure how to explain the extra nibbles.

The full label on the chip we are using:
S32K344HMS 1P55A CTAK2228V

Re: S32K344 RMII Debugging

jay12 — Fri, 29 Mar 2024 16:42:57 GMT

Looking a bit more into the extra clock cycles, if I take the measured packet transmit time and back-calculate what an expected clock frequency for it would be I get a clock frequency of:
48.25 +/- 0.045MHz.

The clock I'm providing for EMAC_RMII_TX_REF is a solid 50MHz so I'm wondering if it could be something in the clock configuration?

This could be grasping at straws here, but we're getting desperate.

Re: S32K344 RMII Debugging

jay12 — Fri, 05 Apr 2024 14:44:54 GMT

We were able to determine that we were splitting the GPIO initialization up into two parts. First, initialize everything related to the FS26 and kick/feed the watchdog for the initial 256ms window. This would happen before the external RMII clock was provided which caused the issue.

So it ended up being a simple bug on our end.

Thanks everyone for the support on this!