NXP - MIMXRT1050 Ethernet fix (HAL_NXP)

[ShahinHaque97-CT]

Hello,

Currently Ethernet does not work on the IMX RT1050, I have a fix that requires a change in HAL_NXP. However, it would not let me post an issue there.

Create Project
west init rt1050EthSupport
cd rt1050EthSupport
west update

Load DHCP example project
cd ..\rt1050EthSupport\zephyr\samples\net\dhcpv4_client

Flash
west build -b mimxrt1050_evk -p

Console reply

*** Booting Zephyr OS build zephyr-v3.4.0-4747-g23ed21c0a028 ***
[00:00:00.500,000] <inf> net_dhcpv4_client_sample: Run dhcpv4 client
[00:00:00.500,000] <inf> net_dhcpv4_client_sample: Start on ethernet@402d8000: index=1
[00:00:00.501,000] <inf> eth_mcux: ETH_0 enabled 100M full-duplex mode.
uart:~$

No further responses

---

Change IGPIO module features from 1 to 0 in ..\rt1050EthSupport\modules\hal\nxp\mcux\mcux-sdk\devices\MIMXRT1052\MIMXRT1052_features.h

/* IGPIO module features */

/* @brief Has data register set DR_SET. */
#define FSL_FEATURE_IGPIO_HAS_DR_SET (0)
/* @brief Has data register clear DR_CLEAR. */
#define FSL_FEATURE_IGPIO_HAS_DR_CLEAR (0)
/* @brief Has data register toggle DR_TOGGLE. */
#define FSL_FEATURE_IGPIO_HAS_DR_TOGGLE (0)

Console reply

*** Booting Zephyr OS build zephyr-v3.4.0-4747-g23ed21c0a028 ***
[00:00:00.500,000] <inf> net_dhcpv4_client_sample: Run dhcpv4 client
[00:00:00.500,000] <inf> net_dhcpv4_client_sample: Start on ethernet@402d8000: index=1
[00:00:02.501,000] <inf> eth_mcux: ETH_0 enabled 100M full-duplex mode.
[00:00:07.535,000] <inf> net_dhcpv4: Received: 192.168.0.49
[00:00:07.535,000] <inf> net_dhcpv4_client_sample:    Address[1]: 192.168.0.49
[00:00:07.535,000] <inf> net_dhcpv4_client_sample:     Subnet[1]: 255.255.255.0
[00:00:07.535,000] <inf> net_dhcpv4_client_sample:     Router[1]: 192.168.0.1
[00:00:07.535,000] <inf> net_dhcpv4_client_sample: Lease time[1]: 86400 seconds
uart:~$

[ShahinHaque97-CT]

@danieldegrasse Is this something you can review?

[robertinant]

Thanks for reporting this. This will save me quite a bit of time figuring out what the problem is. Looking at the history of that file it has been like it is in the current version from the start. So either Ethernet never worked or something else changed that affects these bits. I might have some time later today to look into this and will post here if I find something.

[robertinant]

Alright, with a mimxrt1060_evkb, nxp_hal @ ad142f5 and Zephyr @ v3.4.0-4757-ga6f8935e4fca the out of the box samples/net/dhcpv4_client works like a charm. I looked in our stash of boards to see if I could find a RT1050 but unfortunately I came up empty. Given that I don't have the hardware it will be hard from me to reproduce / fix. I'll ask around on Monday if anybody has a RT1050 board.. As a first I would give the latest Zephyr a try just in case. I'll try the other version of the 1060 board (there are quite a few differences and it has a different dts) and see what that tells me.

*** Booting Zephyr OS build zephyr-v3.4.0-4757-ga6f8935e4fca ***
[00:00:00.501,000] <inf> net_dhcpv4_client_sample: Run dhcpv4 client
[00:00:00.501,000] <inf> net_dhcpv4_client_sample: Start on ethernet@402d8000: index=1
[00:00:02.502,000] <inf> eth_mcux: ETH_0 enabled 100M full-duplex mode.
[00:00:02.531,000] <inf> net_dhcpv4: Received: 10.0.0.173
[00:00:02.531,000] <inf> net_dhcpv4_client_sample:    Address[1]: 10.0.0.173
[00:00:02.531,000] <inf> net_dhcpv4_client_sample:     Subnet[1]: 255.255.255.0
[00:00:02.531,000] <inf> net_dhcpv4_client_sample:     Router[1]: 10.0.0.1
[00:00:02.531,000] <inf> net_dhcpv4_client_sample: Lease time[1]: 172800 seconds

[ShahinHaque97-CT]

@robertinant

I believe this issue is isolated to the RT1050 as I believe it is untested, Unfortunately thought github/discord there isn'tany mention of users using the RT1050 for ethernet projects, however many are using a variant of the RT1060

[robertinant]

I do have a contact at NXP that might be able to help. I'll reach out and see who over there is handling Zephyr.

[DerekSnell]

Hi @ShahinHaque97-CT (and @robertinant ),

The DHCP sample works well for me on my MIMXRT1050-EVKB board. And I believe your issue may be related to an old silicon revision on your EVK. Perhaps you are using the deprecated MIMXRT1050-EVK board?

First, the macros you altered in the HAL define if registers are present in the IGPIO peripheral. They tell the low-level driver from the MCUXpresso SDK if the registers DR_SET, DR_CLEAR, and DR_TOGGLE are present. And from the RT1050 Reference Manual, these registers are present. And these feature macros should not be disabled in the HAL.

But I found a similar issue reported on NXP's support community, see rt1050 DR_SET and DR_CLEAR. And from this, it appears the driver has issues on the older Rev A0 silicon. A0 was used on the original board MIMXRT1050-EVK. NXP replaced that board with the latest MIMXRT1050-EVKB using A1 silicon. And the MCUXpresso SDK support was deprecated for the original board. Since the Zephyr HAL is built on this same SDK, today Zephyr only supports the latest MIMXRT1050-EVKB. The Zephyr doc page for this board has details about this, see Board Revisions.

Can you confirm the silicon and board revision you have that has this issue? In the meantime, I am converting your post from an Issue to a Discussion, and we can continue the conversation there.

For the record, when I tested on my MIMXRT1050-EVKB board, I used the latest Zephyr tag v3.5.0-rc1. Without changes, the DHCP sample works well. My command to build it:

west build -b mimxrt1050_evk samples\net\dhcpv4_client --pristine

And the console output:

*** Booting Zephyr OS build v3.5.0-rc1 ***
[00:00:00.500,000] <inf> net_dhcpv4_client_sample: Run dhcpv4 client
[00:00:00.500,000] <inf> net_dhcpv4_client_sample: Start on ethernet@402d8000: i
ndex=1
[00:00:02.501,000] <inf> eth_mcux: ETH_0 enabled 100M full-duplex mode.
[00:00:02.524,000] <inf> net_dhcpv4: Received: 192.168.87.20
[00:00:02.524,000] <inf> net_dhcpv4_client_sample:    Address[1]: 192.168.87.20
[00:00:02.524,000] <inf> net_dhcpv4_client_sample:     Subnet[1]: 255.255.255.0
[00:00:02.524,000] <inf> net_dhcpv4_client_sample:     Router[1]: 192.168.87.1
[00:00:02.524,000] <inf> net_dhcpv4_client_sample: Lease time[1]: 86400 seconds
uart:~$

Best regards

[ShahinHaque97-CT]

@DerekSnell -

I have checked and yes unfortunately I am using an older silicon version.

[ShahinHaque97-CT]

I have managed to get Ethernet working on the RT1040, which I will continue with.
Thank you for your help

[danielwippermann]

Hi everybody!

Could something similar also affect the i.MX RT1020 EVK? I can only get the dhcpv4_client sample to work if I had previously flashed and run an ethernet example using MCUXpresso and then (without pushing the RESET button or power-cycling the hardware) west flash-ing the dhcpv4_client sample on the same board. Then it runs perfectly fine, fetches an IP and can be pinged. If I then push RESET or power-cycle the board, it shows the same behaviour as the OP reported: it gets stuck attempting to contact the DHCPv4 server:

Working example:

*** Booting Zephyr OS build zephyr-v3.5.0-2951-gbd227e19cff9 ***
[00:00:00.501,000] <inf> net_dhcpv4_client_sample: Run dhcpv4 client
[00:00:00.501,000] <inf> net_dhcpv4_client_sample: Start on ethernet@402d8000: index=1
[00:00:02.502,000] <inf> eth_mcux: ETH_0 enabled 100M full-duplex mode.
[00:00:08.052,000] <inf> net_dhcpv4: Received: 192.168.180.245
[00:00:08.052,000] <inf> net_dhcpv4_client_sample:    Address[1]: 192.168.180.245
[00:00:08.052,000] <inf> net_dhcpv4_client_sample:     Subnet[1]: 255.255.255.0
[00:00:08.053,000] <inf> net_dhcpv4_client_sample:     Router[1]: 192.168.180.1
[00:00:08.053,000] <inf> net_dhcpv4_client_sample: Lease time[1]: 600 seconds
uart:~$

After pushing the RESET button or power-cycling the board:

*** Booting Zephyr OS build zephyr-v3.5.0-2951-gbd227e19cff9 ***
[00:00:00.501,000] <inf> net_dhcpv4_client_sample: Run dhcpv4 client
[00:00:00.501,000] <inf> net_dhcpv4_client_sample: Start on ethernet@402d8000: index=1
[00:00:02.502,000] <inf> eth_mcux: ETH_0 enabled 100M full-duplex mode.
uart:~$ net iface

Interface eth0 (0x80000ba8) (Ethernet) [1]
===================================
Link addr : XX:XX:XX:XX:XX:XX
MTU       : 1500
Flags     : AUTO_START,IPv4
Device    : ethernet@402d8000 (0x600173e8)
Ethernet capabilities supported:
	Virtual LAN
	Auto negotiation
	10 Mbits
	100 Mbits
IPv4 unicast addresses (max 1):
	<none>
IPv4 multicast addresses (max 2):
	224.0.0.1
IPv4 gateway : 0.0.0.0
IPv4 netmask : 0.0.0.0
DHCPv4 lease time : 0
DHCPv4 renew time : 0
DHCPv4 server     : 0.0.0.0
DHCPv4 requested  : 0.0.0.0
DHCPv4 state      : selecting
DHCPv4 attempts   : 69
uart:~$

My board too has a silicon rev A0 chip on there (PIMXRT1021DAG5A).

Or am I missing something obvious?

Thanks in advance,
Daniel

[DerekSnell]

Hi @danielwippermann ,
Thank you for reporting this issue. This is a different issue than the Discussion above, but I did replicate the problem you reported. So I have created a new Issue at #66576. Please use this Issue for further work on this topic.

FYI, it is a different issue because the problem initially reported here was on different silicon, the RT1050. And specifically an old silicon revision that has been deprecated in the MCUXpresso SDK, used by the Zephyr HAL. Therefore the HAL code was not properly configuring the deprecated silicon.

However, the issue you reported is on supported silicon, and appears to be a regression issue in Zephyr. See the new Issue for more details.

Best regards

[danielwippermann]

Thank you, @DerekSnell for the quick and informative response. I'll be closely watching the other issue for progress, but for the meantime have switched to a 1064EVK to continue development until my custom hardware arrives.

Best regards, Daniel