How to enable RT1064 ENET2?

[tmeyer1]

Hi,

I have a custom board with a RT1064 connected to a Ethernet switch via RMII. I'm using MCUXpresso IDE v11.02 with MCU SDK v2.62 and I've modified the code to communicate to the switch over SMI instead of the PHY attached to the 1064 EVK. 

The issue is that I cannot see any changes/rises on the TX_EN or TX_Dx lines when. I do see a 50MHz clock and can also see data on the RX lines when I send data to the switch from another source. I also noticed that the ENET_TransmitIRQHandler() [fsl_enet.c:3007] is never called despite several calls into ENET_ActiveSend() [fsl_enet.c:885].  

I'm inclined to think it is related to the ENET2 clocking, but I cannot figure how to get it right so that data is sent on the ENET2 data lines. The switch may be configured to either provide a 50MHz clock or have a 50MHz input clock which I have connected GPIO_B0_15 (ENET2_REF_CLK or ENET2_TX_CLK). I can get the physical clock to be produced in either direction by changing the following:

IOMUXC_EnableMode(IOMUXC_GPR, kIOMUXC_GPR_ENET2RefClkMode, false);
IOMUXC_EnableMode(IOMUXC_GPR, kIOMUXC_GPR_ENET2TxClkOutputDir, true);

I can't help but wonder if the internal ENET peripheral isn't being clock despite the clock output on E11. Is this possible? No matter what I change these two, I never see any data or TX interrupt. 

Any other ideas what I am missing?

Pin mux

By the way, I also had changed the following line to fix a out of bounds access issue with ENET2, fsl_enet.c:264 

/*! @brief Pointers to enet handles for each instance. */
static enet_handle_t *s_ENETHandle[] = {NULL,NULL,NULL};

Also,

I've attached a simple variation (with .git) of the lwip_udpecho_freertos which shows the same results. I can send data from the switch and I see the RXDx and CRS lines being changed going into the 1064. I never see any change on the TX lines nor are the TX or RX interrupts ever entered. 

Any advice would be appreciated. 

Thanks,

Tim

[pconway]

Hello,

Just following up on a related discussion with Victor, have also been having issues with ENET2 configuration. This is from RT1062 with a KSZ8895 switch chip supplying the 50MHz clock in RMII mode, on a prototype development PCB.

We have worked through the snagging points found by Tim above, and found that (1-3) were items we had already come across and resolved. We have now also applied (4) to our configuration by moving all data to DTC RAM, since caching of ethernet descriptor buffers may have been an issue.

However, we observe that while packets appear to be transmitted from the ENET2 of MCU to the switch/PHY chip during a ping test, we are not receiving anything back from the switch/PHY. This is apparent from the ENET2 statistics registers (MIB counters) and from scoping data on the lines between the switch/PHY and MCU.

Have others encountered similar issues and found possible solutions, in addition to those found by Tim above?

Thanks for your help!

Patrick

[pconway]

Hi,

Just to update in case others face a similar issue...

It turned out our configuration of ENET2 on RT1062, and the solutions already suggested on this post, were sound. The issue was on the PHY/switch side (a KSZ8895 device), which was essentially starting up in a mode where the switch was not enabled. This resulted in no RX traffic from the PHY/switch back to the MCU. With this fixed, we are able to successfully use the ethernet interface.

Kind regards,

Patrick

[tmeyer1]

Hi Victor,

Thanks for looking into this. The all calls to the switch/PHY are essentially disabled. IF you look at the PHY read/write functions do not actually do any reads/writes. It is assumed the the switch is configured via bootstrap pins. 

I've managed to make it one step further. I am now seeing some interrupts getting called. This was fixed via the "software input" bit on the GPIO mux of the REF_CLK. With this change alone I've managed to see a little bit of success. 

index d056f67..8ed1ee2 100644
--- a/board/pin_mux.c
+++ b/board/pin_mux.c
@@ -95,10 +95,7 @@ void BOARD_InitPins(void) {
0U); /* Software Input On Field: Input Path is determined by functionality */
IOMUXC_SetPinMux(
IOMUXC_GPIO_B0_15_ENET2_REF_CLK2, /* GPIO_B0_15 is configured as ENET2_REF_CLK2 */
- 0U); /* Software Input On Field: Input Path is determined by functionality */
- IOMUXC_SetPinMux(
- IOMUXC_GPIO_B1_00_ENET2_RX_ER, /* GPIO_B1_00 is configured as ENET2_RX_ER */
- 0U);
+ 1U); /* Software Input On Field: Force input path of pad GPIO_B0_15 */^M
IOMUXC_SetPinMux(
IOMUXC_GPIO_B1_01_ENET2_RDATA00, /* GPIO_B1_01 is configured as ENET2_RDATA00 */
0U); /* Software Input On Field: Input Path is determined by functionality */

Thanks,

Tim

[victorjimenez]

Hello, Tim 

Just to confirm, now you can see interrupts getting called but still nothing on the TX lines? 

Regards, 

Victor 

[tmeyer1]

Furthermore, I have verified all the RMII signals. They all look as expected. As I mentioned before, the TX seems to be working fine. The RX is not. I have confirmed that the RX signals look synchronized to the ref_clk and appear as per "Figure 40-19. RMII receive operation" in the RT1064 reference manual.

There is related point one point that eludes me: The RMII_CRS_DV signal is mentioned for both the ENET_CRS & ENET_RX_EN signal description. My custom board has the "RX enable" from the switch connected to ENET2_CRS signal (pad GPIO_B0_10) I've also tried a external mod with the the ENET2_RX_EN pin without success.

Q: Which is the correct method to wire this?

Note: I've tried sourcing the 50MHz clock from both the switch and also from the RT1064. In either case the signals look the same. 

I'm looking for some direction on how to further troubleshoot this assume that

- ENET RX Interrupt are enabled, RDAR is being set

- The RX signals are present

- no interrupt 

- I don't see any errata related to ENET2, (however I've yet to find anyone that uses ENET2 on this part)

Thanks in advance. 

Tim

[tmeyer1]

I was able to make a little progress by double checking the mod I made to change the over to use the ENET_RX_EN input. This resulted in producing some rx error interrupts upon receiving data. This is promising in the sense that it seems to imply that I need to use ENET_RX_EN and not ENET_CRS. 

I've yet to troubleshoot this much further, but the fsl_enet driver is accessing a NULL pointer. I had commented out the culprit line causing the hard fault (s_enetErrIsr is NULL):

--- a/Software/ECU/bic-ecu/drivers/fsl_enet.c
+++ b/Software/ECU/bic-ecu/drivers/fsl_enet.c
@@ -3252,7 +3252,7 @@ void ENET_CommonFrame0IRQHandler(ENET_Type *base)
}
if (event & ENET_ERR_INTERRUPT)
{
- s_enetErrIsr(base, s_ENETHandle[instance]);
+ //s_enetErrIsr(base, s_ENETHandle[instance]);^M
}
/* Add for ARM errata 838869, affects Cortex-M4, Cortex-M4F Store immediate overlapping
exception return operation might vector to incorrect interrupt */

[victorjimenez]

Hello Tim, 

Sorry for the late response, there was a mix-up with the cases. Are you still facing some problems with the ENET2?

Regards, 

Victor 

[tmeyer1]

Hi Victor,

I am still struggling with getting ENET2 working. I haven't been focused on it much, but did revisit it again.

I have no confidence that fsl_enet even works for the 2nd Ethernet port. Are you aware of any customers or boards that have fsl_enet and lwip working with ENET2? Knowing this would be helpful in my debugging. I have a 2nd board sping coming which I had the Ethernet moved to ENET1, this will hopefully be on my desk in ~6 weeks or less. 

The current status is that I am now seeing interrupts both directions.

TX: I will see only 1 UDP data gram that makes it out of the 1064. Max of 2 interrupts (sends) are seen, then the udp send function blocks forever

RX: I will receive 5 interrupts then no more.No data is ever seen in at the lwip UDP level. 

I will continue to troubleshoot this some, but I may give up and wait for the board to use ENET1. 

Thanks,

Tim

[tmeyer1]

I've a work-around down to commenting out a call to SCB_EnableDCache(); I haven't traced it down to a specific memory access yet, so I don't know why exactly this fixes it. I figured I would share my findings thus... 

A change that I introduces this bug: I have moved the global data including the FreeRTOS heap_4 to SRAM_OC. This error occurs whether my MPU is enabled or disabled, but disabling the DCache will fix it regardless of the state of the MPU. 

I've also tried adding the lwip option below, with no effect:

#define LWIP_MPU_COMPATIBLE 1

If anyone has has any advice on this - please let me know.

Thanks,

Tim

[tmeyer1 · Accepted solution]

I believe that I have resolve all my issues. Thanks for all your help.

To recap them all:

1. I needed to use RX_EN input and not CRS signal
2. Use 50MHz clock from external switch:Enable it:
   IOMUXC_EnableMode(IOMUXC_GPR, kIOMUXC_GPR_ENET2RefClkMode, true);
   IOMUXC_EnableMode(IOMUXC_GPR, kIOMUXC_GPR_ENET2TxClkOutputDir, false);
3.  REF_CLK pin needs be configured with "Software Input On" 
4. And my final(hopefully) issue was that I didn't have "*(NonCacheable.init)" mapped to DTC.

Note there is still a bug in the enet driver: + //s_enetErrIsr(base, s_ENETHandle[instance]);

Tim

[tmeyer1]

Hi Victor,

The current status is:

TX interrupts and signals seem to be working now. I can send data from the 1064 through the switch to my workstation which is also attached to the switch. However I am now struggling to get the RX interrupt to fire when I send data in the reverse direction. I can see the RX CRS and RX Dx signals change accordingly between the 1064 and switch, however never are any RX interrupts are fired.

I'm working through why this could be, if you have suggestions on where to look I'd appreciate it. 

Thanks,

Tim

[victorjimenez]

Hello, Tim 

I noticed in your project that you didn't modify the value of the macro EXAMPLE_PHY_ADDRESS, could you please confirm that the address of your ENET2 PHY is 2? 

Regards, 

Victor