Cannot transmit/receive Ethernet frames Cortex-M4 on RT1170-EVK

[D_TTSA]

Good day

I am working on a multi-core project with the RT1170-EVK in MCUXpresso, where the M7 controls the M4, and the M4 must transmit and receive Ethernet frames. 

I have adapted the main function of the enet_txrx_transfer_cm4 example to work with MCMGR, so that the M7 successfully calls my M4 project, which then runs the exact same code as the enet_txrx_transfer_cm4 example.

I have connected the EVK to an Ethernet loopback cable via the 100M ENET connection.

The PHY initialises and successfully auto-negotiates, but it does not successfully communicate.

The PRINTF statements show that the frames were transmitted 'successfully' according to the code, but no data is received (ENET_GetRxFrameSize returns status 4002 - line empty).

The pinmux.c file in the M7 master project is identical to that in the example project.

I put it in the M7 project and not the M4 project because configtools won't let me change the pinmux of the M4 project (I get a warning: "Function core cortex-M7F differs from selected active core cortex-M4F.", which blocks the pinmux file from being changed when I press 'update code').

I suspect that the Ethernet communication problem has something to do with how the M7 transfers control over to the M4... is it possible that only the M7 can control the pins that have been set in its pinmux.c file?

In other words, the M4 cannot control the necessary pins for ethernet communication, because it is only set in the M7 project's pinmux file?

If this is the case, could someone please tell me how to get around the slave M4's configtools limitation.

Thank you in advance

[D_TTSA · Accepted solution]

I managed to fix it myself.

For anyone facing a similar issue: make sure that the SRAM_DTC address in the M4 project's linker script is the alias address (0x20220000) and not the actual address (0x20000000).

The address in the M7 project's linker script must also be the aliased address.

Clearly this lets the M7 access the M4's memory, to get hold of the Ethernet data to transmit.

[FelipeGarcia]

Hi,

I personally do not think it is a PHY configuration issue. For your other post in the community it seems that the project works if it is not a slave project, is this correct?

Regarding your question about pinmux.c file, you should be able to configure pins in slave project, you can check multicore_manager example that configures a GPIO to toggle a led on the slave project.

Best regards,

Felipe

[D_TTSA]

Hello @FelipeGarcia 

Thank you for your answer.

Yes, I created an M4 standalone project, which works as expected.

With regards to the pinmux problem, please see the image below, where the  evkmimxrt1170_rpmsg_lite_pingpong_cm4 SDK example project has the same error:

This is weird because GPIO pin is in the M4's pinmux.c, but I cannot get configTools to edit the pinmux.c.

Please see my other forum post (https://community.nxp.com/t5/i-MX-RT/Cannot-use-ConfigTools-for-Pinmux-in-M4-Slave-project-for-RT117...) for my question on this specifically (it is unanswered).

I agree with you though, I don't think this is the problem, since the PHY initialises and performs auto-negotiation correctly (according to the example code PRINTF statements anyway) with the pinmux in the M7 Master project. Also, to verify that it isn't a pinmuxing problem, I copied the pinmux.c file from my working M4 standalone project to this project, and I still had the same no-transmit error.

[D_TTSA]

Another update (@FelipeGarcia):

I captured some packets using Wireshark to see if my project is indeed not transmitting.

To my surprise, it was transmitting, but the data is just completely jumped. This is extremely strange though, since the jumbled packets seem to repeat themselves every 4 packets.

I checked the contents of the frame (in the software) before it is transmitted, and it is correct.

Here is a screenshot (I can't upload the .pcapng) of the packets received from my project:

and a screenshot of the packets received from the example project:

The frames captured should be equivalent when my project is working correctly.

If anyone could share why the Ethernet data would be jumbled like this, it would be much appreciated.

Kind regards

[D_TTSA]

Another update:

I realised that the repetition every 4 packets is not a coincidence.

My TX & RX buffer size in the code was 4 frames.

When I increased the buffer sizes to 5, the packet contents was repeated every 5 frames.

As a result, I am confident that my problem is to do with how the data is copied into this buffer.

Any help would be appreciated.

Kind regards

[D_TTSA]

Update: 

I used an oscilloscope to check whether the board was transmitting information or not.

I used the trigger function on TP3, which confirmed that the data is indeed being transmitted on ENET_TXD0. However, I get a very weird voltage on ENET_TXP and ENET_TXM - 3.3V mean with a max of 3.7V (above the power supply to the PHY of 3.3V, and a very large pk-pk reading of 0.9V).

I measured the same signals with the enet_txrx_transfer_cm4 SDK example project running, and got a 1.6V mean with a similar ripple. This is what I expect from these signals.

I think there is something wrong with the PHY's configuration?

Any help would be much appreciated.