Solved! Go to 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.
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.
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
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.
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
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
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.