LAN865x not working with RT1170 & RT1064 (likely caused by LPSPI issues) #69658

mariopaja · 2024-03-01T10:03:52Z

We have been testing the LAN865x driver and we have had problems with RT1064 and RT1170.

Our main focus was NXP RT1064 but we were not able to implement LAN865x and therefore ended up testing it with several MCU to see what is going wrong.

From the table below it seems that LAN865x works totally fine with other ARM, RISK-V & XTENSA MCUs but not with RT1064 & RT1170

DEV Board	Result
NUCLEO-F207ZG	OK
NUCLEO-F429ZI	OK
NUCLEO-L552ZE-Q	OK
NUCLEO-U575ZI-Q	OK
NUCLEO-H745ZI-Q	OK
Arduino Giga R1	OK
B-U585I-IOT02A	OK
XIAO ESP32C3	OK
XIAO ESP32S3	OK
RT1064	FAILED
RT1170	FAILED

XIAO ESP32C3

XIAO ESP32S3

NUCLEO H563

RT1170 LAN865x

RT1064

Additionally a test with W5500 module
RT1170 W5500

aescolar · 2024-03-05T15:35:10Z

CC @decsny @lmajewski
This driver seems to have been written by @lmajewski but he does not seem to be a Zephyr collaborator so I cannot assign it to him

decsny · 2024-03-05T19:24:15Z

If you can narrow down if it is an LPSPI issue or LAN865 issue that would be helpful because I don't have a LAN865, and the author of the driver most likely does not have a platform with LPSPI. Since you said it works on other platforms, maybe you can compare the SPI signals with a signal analyzer between those platforms and the RT1064 to see where is the difference as your next step in debugging.

lmajewski · 2024-03-06T09:08:49Z

@mariopaja - I only had the Nucleo Devel board for T1S development. I've tried to use the Zephyr kernel's well defined APIs, so I assume that semaphores shall work in the same way cross platform.

From the above comment - XIAO ESP32C3 is a RISC-V SoC, so it looks like at least on other SoC it works.

Could you share which HW revision of LAN8651 do your have? (B0 or B1)
With B0 for example I had issues with SW reset - hence the GPIO reset is used (and recommended).
As advised by @decsny - comparing the SPI signals would be a good starting point.

Just a side note - I shall have come back to this driver in short time, as the full duplex transmission needs to be finished (now it is a very simple, working half-duplex driver).

mariopaja · 2024-03-06T21:03:56Z

@lmajewski

with RISK-V yes. I would definitely have to do a second test round with all the MCUs.
We are using B0 variant. And btw thank you a lot for the support of this driver :)

@decsny

I am also suspicious on the driver itself because I have faced issues with the chip select, and there are other developers that are mentioning that they are facing difficulties like #69692 (comment).

These made me a bit suspicious and confused because these two issues are not directly related to each other. I will be able to provide the SPI signals for STM, NXP, & ESP32-S3/C3 by the end of the next working week.

decsny · 2024-03-06T21:24:03Z

I am also suspicious on the driver itself because I have faced issues with the chip select, and there are other developers that are mentioning that they are facing difficulties like #69692 (comment).

There is this issue with the LPSPI CS tracked here: #16544 , maybe consider if this is a cause

mariopaja · 2024-03-13T13:07:58Z

@lmajewski
lan865x driver seems to be fine. I was able to make it work with also with xiao_esp32s3 (XTENSA).

@decsny
I checked the rt1170 and the signal seems kind of inverted. Maybe it is not a bug, maybe I have configured the SPI wrong :/
At the moment I am using the following configuration:

&lpspi1 {
  status = "okay";
  cs-gpios = <&gpio3 28 GPIO_ACTIVE_LOW>; /* D10 */
  eth0: lan865x@0{
    status = "okay";
    compatible = "microchip,lan865x";
    reg = <0>;
    int-gpios = <&gpio3 6 GPIO_ACTIVE_LOW>; /* D9 */
    rst-gpios = <&gpio3 0 GPIO_ACTIVE_LOW>; /* D8 */
    local-mac-address = [00 19 05 00 00 04];
    spi-max-frequency = <20000000>;
    plca-enable;
    plca-node-id = <3>;
    plca-node-count = <8>;
    plca-burst-count = <0x0>;
    plca-burst-timer = <0x80>;
    plca-to-timer = <0x20>;

  };
};

mariopaja · 2024-04-10T08:04:28Z

@lmajewski

I was able to point the error to:

zephyr/drivers/ethernet/oa_tc6.c

Line 309 in ca527d9

int oa_tc6_read_status(struct oa_tc6 *tc6, uint32_t *ftr)

before getting the following error:
spi_mcux_lpspi: Transfer could not start on spi@40394000: 4

and is is either transmitting the first 3 bytes of the header and then the SPI stops transmitting or the SPI doesnt start the transmittion at all like the image below:

@decsny It also seems like the SPI is transmitting 16 bytes at a time without any delay between each byte transmission (image below). Maybe this is creating a bottleneck.

Is there a possibility to lower the transmission speed between the bytes and make it look more like the behaviour of STM32 H563 (image below)?

mariopaja · 2024-04-10T13:22:15Z

@lmajewski for further testing I added the following code to

zephyr/drivers/ethernet/oa_tc6.c

Line 272 in ca527d9

    
           int oa_tc6_chunk_spi_transfer(struct oa_tc6 *tc6, uint8_t *buf_rx, uint8_t *buf_tx,

and only then I was able to transmit the spi chunk and deassert the interrupt.

...
#ifdef CONFIG_BOARD_MIMXRT1064_EVK
		int ret;

		uint8_t tx_cmd[OA_TC6_HDR_SIZE+64]={0};
		hdr = sys_cpu_to_be32(hdr);
		//LOG_ERR("hdr: %x", hdr);

		//tx_cmd[0]=hdr[0];
		tx_cmd[3]=(hdr >> 24) & 0xFF;
		tx_cmd[2]=(hdr >> 16) & 0xFF;
		tx_cmd[1]=(hdr >> 8) & 0xFF;
		tx_cmd[0]=(hdr) & 0xFF;

		if(buf_tx!=NULL){
			//LOG_ERR("buf_tx!=NULL");
			//TODO: Do smth
			for(int i=4;i<68;i++){
				//LOG_ERR("buf_tx: 0x%x",*buf_tx);
				tx_cmd[i]=*buf_tx;
				buf_tx++;
			}

		}


		struct spi_buf tx_buf={.buf = &tx_cmd, .len = ARRAY_SIZE(tx_cmd),};
		struct spi_buf_set tx = {.buffers = &tx_buf, .count = 1,};

		uint8_t rx_cmd[64+OA_TC6_FTR_SIZE]={0};

		if(buf_rx!=NULL){
			LOG_ERR("buf_rx!=NULL");
			//TODO: Do smth
		}

		const struct spi_buf rx_buf = {.buf = rx_cmd, .len = ARRAY_SIZE(rx_cmd),};
		const struct spi_buf_set rx = {.buffers = &rx_buf, .count = 1,};

		ret = spi_transceive_dt(tc6->spi, &tx, &rx);
		if (ret < 0) {
			return ret;
		}
		//LOG_ERR("rx_cmd[64]: %x", rx_cmd[64]);

		uint32_t data;
		data=rx_cmd[67];
		data|=rx_cmd[66]<<8;
		data|=rx_cmd[65]<<16;
		data|=rx_cmd[64]<<24;

		*ftr=data;

#else

...

mariopaja · 2024-04-11T05:57:19Z

@lmajewski I finished the patch today for the rt1064 and I could get the expected behaviour and transmit & recevie packets.

@decsny Is there any particular reason why it would work with one and not with the other?

int oa_tc6_chunk_spi_transfer(struct oa_tc6 *tc6, uint8_t *buf_rx, uint8_t *buf_tx, uint32_t hdr,
			      uint32_t *ftr)
{
	// Correct behaviour
#ifdef CONFIG_BOARD_MIMXRT1064_EVK
	int ret;

	uint8_t tx_cmd[OA_TC6_HDR_SIZE + 64] = {0};
	hdr = sys_cpu_to_be32(hdr);
	// LOG_ERR("hdr: %x", hdr);

	// tx_cmd[0]=hdr[0];
	tx_cmd[3] = (hdr >> 24) & 0xFF;
	tx_cmd[2] = (hdr >> 16) & 0xFF;
	tx_cmd[1] = (hdr >> 8) & 0xFF;
	tx_cmd[0] = (hdr) & 0xFF;

	if (buf_tx != NULL) {
		for (int i = 4; i < 68; i++) {
			tx_cmd[i] = *buf_tx;
			buf_tx++;
		}
	}

	struct spi_buf tx_buf = {
		.buf = &tx_cmd,
		.len = ARRAY_SIZE(tx_cmd),
	};
	struct spi_buf_set tx = {
		.buffers = &tx_buf,
		.count = 1,
	};

	uint8_t rx_cmd[64 + OA_TC6_FTR_SIZE] = {0};

	const struct spi_buf rx_buf = {
		.buf = rx_cmd,
		.len = ARRAY_SIZE(rx_cmd),
	};
	const struct spi_buf_set rx = {
		.buffers = &rx_buf,
		.count = 1,
	};

	ret = spi_transceive_dt(tc6->spi, &tx, &rx);
	if (ret < 0) {
		return ret;
	}

	for (int i = 0; i < 64; i++) {
		*buf_rx = rx_cmd[i];
		buf_rx++;
	}

	uint32_t data;
	data = rx_cmd[67];
	data |= rx_cmd[66] << 8;
	data |= rx_cmd[65] << 16;
	data |= rx_cmd[64] << 24;

	*ftr = data;

#else
	struct spi_buf tx_buf[2];
	struct spi_buf rx_buf[2];
	struct spi_buf_set tx;
	struct spi_buf_set rx;
	int ret;

	hdr = sys_cpu_to_be32(hdr);
	tx_buf[0].buf = &hdr;
	tx_buf[0].len = sizeof(hdr);

	LOG_ERR("sizeof(hdr): %d", sizeof(hdr));

	tx_buf[1].buf = buf_tx;
	tx_buf[1].len = tc6->cps;
	LOG_ERR("tc6->cps: %d", tc6->cps);

	tx.buffers = tx_buf;
	tx.count = ARRAY_SIZE(tx_buf);

	rx_buf[0].buf = buf_rx;
	rx_buf[0].len = tc6->cps;

	rx_buf[1].buf = ftr;
	rx_buf[1].len = sizeof(*ftr);

	rx.buffers = rx_buf;
	rx.count = ARRAY_SIZE(rx_buf);

	ret = spi_transceive_dt(tc6->spi, &tx, &rx);
	if (ret < 0) {
		return ret;
	}
	*ftr = sys_be32_to_cpu(*ftr);

#endif

	return oa_tc6_update_status(tc6, *ftr);
}

lmajewski · 2024-04-12T10:36:30Z

@mariopaja - Am I correct, that you need to delay the transmission start between sending first byte and the CS being low? As well as your's CPU (to talk with LAN965x) requires some time between sending each byte?

Is there a possibility to lower the transmission speed between the bytes

The SPI transmission shall not impact the TC6 driver - it shall be tuned in the CPU setup code. It looks like the issue is either with the way LAN8651 is communicating via SPI or with the NXP's RT1170 HAL's SPI driver.

Could you check if LAN8651 documentation has any requirements for it? Maybe you's SPI setup (like polarity or CLK frequency) is different than that required?

Could you also check if lowering the SPI frequency helps with the communication stability on your setup?

mariopaja · 2024-04-12T11:39:24Z

@lmajewski I think it has to do with the MCUX SPI HAL, because the issue arises as TC6 tries to transmit 4 bytes of the header.

It looks like the issue is either with the way LAN8651 is communicating via SPI or with the NXP's RT1170 HAL's SPI driver.

For this reason I circumvented this issue with the patch here: #69658 (comment). Instead of providing two buffers at different lengths I give one big buffer to SPI. As a solution it may be enough for our case but it is at no means a good solution.

lmajewski · 2024-04-12T20:14:49Z

@mariopaja - I do have an impression that the patch you mentioned would we OK only for some short time.... In the long term IMHO it would be better to have this issue investigated and correctly fixed in the HAL. Maybe NXP's maintainers (especially for HAL) shall be informed about the issue? Maybe they could look on this problem?

github-actions · 2024-06-13T00:29:43Z

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

decsny · 2024-06-24T21:04:27Z

@mariopaja I have been looking into the lpspi driver lately because of various other issues, and I have a feeling they are related to your issue with this. For example, the chip select is not remaining asserted throughout the whole transfer, that could be the issue, or a host of other ones that I am finding. Basically, the lpspi driver is not even implementing the zephyr api correctly in my opinion at all. I am doing a major rework of this driver that probably will not show up until after LTS because it is too major of a change for this current release cycle.

github-actions · 2024-08-24T00:29:58Z

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

github-actions · 2025-01-08T00:34:17Z

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

mariopaja · 2025-01-09T07:19:42Z

Hi @decsny,
Is there any significant changes on the driver that would be interesting to test it out once again and see if the issue is gone?

decsny · 2025-01-09T16:31:41Z

@mariopaja it is WIP but might be interesting to try #82877 version of the lpspi driver which I have working on RT series. To be clear I do not know what is the actual issue on this ticket, that PR is addressing another issue but it totally rewrites the driver from scratch so maybe it has as different behavior for you. And it should remove the HAL from the equation.

decsny · 2025-01-29T17:06:26Z

@mariopaja it is WIP but might be interesting to try #82877 version of the lpspi driver which I have working on RT series. To be clear I do not know what is the actual issue on this ticket, that PR is addressing another issue but it totally rewrites the driver from scratch so maybe it has as different behavior for you. And it should remove the HAL from the equation.

This PR is more robust now so I highly recommend to try it.

In addition to that, there are these three configuration options of the LPSPI hardware that are currently supported in the binding:

zephyr/dts/bindings/spi/nxp,lpspi.yaml

Lines 17 to 34 in 3df9b5f

    
             pcs-sck-delay: 
        
               type: int 
        
               description: | 
        
                 Delay in nanoseconds from the chip select assert to the first clock 
        
                 edge. If not set, the minimum supported delay is used. 
        
             sck-pcs-delay: 
        
               type: int 
        
               description: | 
        
                 Delay in nanoseconds from the last clock edge to the chip select 
        
                 deassert. If not set, the minimum supported delay is used. 
        
             transfer-delay: 
        
               type: int 
        
               description: | 
        
                 Delay in nanoseconds from the chip select deassert to the next chip 
        
                 select assert. If not set, the minimum supported delay is used.

I think you should try configuring those how you need, especially the transfer-delay property, seems to address most directly some speculation you had about there being 0 delay between the bytes being transferred in your posts/screenshots above. The description of this property is actually not accurate since we are using a continuous transfer in the driver, so I'll update that description in the PR I have too. The actual behavior of that property is it sets a delay between transfer words within the continuous transfer, which in your case is probably bytes like you mentioned.

mariopaja · 2025-01-30T13:09:05Z

Hi @decsny,

I tried your suggestions on mimxrt1064_evk and the issue is still persistant.

&lpspi1 {
    status = "okay";
    transfer-delay=<100>;
    eth0: lan865x@0 {
        status = "okay";
        compatible = "microchip,lan865x";
        reg = <0>;
        int-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>; /* D9 */
        rst-gpios = <&gpio1 3 GPIO_ACTIVE_LOW>; /* D8 */
        local-mac-address = [ 00 19 05 00 00 04  ];
        spi-max-frequency = <20000000>;
        lan865x_mdio: lan865x_mdio {
            compatible = "microchip,lan865x-mdio";
            status = "okay";
            #address-cells = <1>;
            #size-cells = <0>;
            ethernet-phy@0 {
                compatible = "microchip,t1s-phy";
                reg = <0x0>;
                plca-enable;
                plca-node-id = <0>;
                plca-node-count = <8>;
                plca-burst-count = <0>;
                plca-burst-timer = <0x80>;
                plca-to-timer = <0x20>;
                status = "okay";
            };
        };
    };
};

[00:00:00.000,000] <err> oa_tc6: Header transmission error!
[00:00:00.000,000] <err> eth_lan865x: SPI communication not working, -19
[00:00:00.000,000] <err> oa_tc6: Header transmission error!
[00:00:00.000,000] <err> phy_mc_t1s: Failed MII_PHYID1R register read: -1

[00:00:00.000,000] <err> oa_tc6: Header transmission error!
[00:00:00.000,000] <err> eth_lan865x: LAN865x sync enable failed: -1

*** Booting Zephyr OS build v4.0.0-4279-g943a93667d05 ***
[00:00:00.001,000] <inf> net_dhcpv4_client_sample: Run dhcpv4 client
[00:00:00.001,000] <inf> net_dhcpv4_client_sample: Start on lan865x@0: index=1
uart:~$

decsny · 2025-01-30T13:30:36Z

Hi @decsny,

I tried your suggestions on mimxrt1064_evk and the issue is still persistant.

&lpspi1 {
    status = "okay";
    transfer-delay=<100>;
    eth0: lan865x@0 {
        status = "okay";
        compatible = "microchip,lan865x";
        reg = <0>;
        int-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>; /* D9 */
        rst-gpios = <&gpio1 3 GPIO_ACTIVE_LOW>; /* D8 */
        local-mac-address = [ 00 19 05 00 00 04  ];
        spi-max-frequency = <20000000>;
        lan865x_mdio: lan865x_mdio {
            compatible = "microchip,lan865x-mdio";
            status = "okay";
            #address-cells = <1>;
            #size-cells = <0>;
            ethernet-phy@0 {
                compatible = "microchip,t1s-phy";
                reg = <0x0>;
                plca-enable;
                plca-node-id = <0>;
                plca-node-count = <8>;
                plca-burst-count = <0>;
                plca-burst-timer = <0x80>;
                plca-to-timer = <0x20>;
                status = "okay";
            };
        };
    };
};

[00:00:00.000,000] <err> oa_tc6: Header transmission error!
[00:00:00.000,000] <err> eth_lan865x: SPI communication not working, -19
[00:00:00.000,000] <err> oa_tc6: Header transmission error!
[00:00:00.000,000] <err> phy_mc_t1s: Failed MII_PHYID1R register read: -1

[00:00:00.000,000] <err> oa_tc6: Header transmission error!
[00:00:00.000,000] <err> eth_lan865x: LAN865x sync enable failed: -1

*** Booting Zephyr OS build v4.0.0-4279-g943a93667d05 ***
[00:00:00.001,000] <inf> net_dhcpv4_client_sample: Run dhcpv4 client
[00:00:00.001,000] <inf> net_dhcpv4_client_sample: Start on lan865x@0: index=1
uart:~$

looking at the datasheet for the LAN8650, you need to set pcs-sck-delay to at least 8, and sck-pcs-delay to at least 14. Also, I can see the maximum frequency is 25 MHz and you are setting it to 20, which should be fine, but the example linux DT given by microchip only set its to 15 MHz, so maybe try that just to see if the result is different. It seems like your 100 ns transfer-delay should be fine.

decsny · 2025-01-30T15:13:16Z

for reference, this is where I got those numbers:

mariopaja · 2025-01-31T08:58:13Z

Hi @decsny,

I was finaly able to make the lan865x work. The initialization seems succesful without any errors. However, at the moment I am not able to test it further.

BTW, something that I noticed:
The maximal frequency that I could set is 2MHz.
If the frequency was set higher, the SCK was unstable. But in any case It is great that the PR addressed also this issue 👍🏻

Will this PR be backported to v3.7 LTS?

MIMXRT1064_EVK Overlay:

&lpspi1 {
    status = "okay";
    transfer-delay=<200>;
    pcs-sck-delay=<100>;
    sck-pcs-delay=<100>;
    eth0: lan865x@0 {
        status = "okay";
        compatible = "microchip,lan865x";
        reg = <0>;
        int-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>; /* D9 */
        rst-gpios = <&gpio1 3 GPIO_ACTIVE_LOW>; /* D8 */
        local-mac-address = [ 00 19 05 00 00 04  ];
        spi-max-frequency = <2000000>;
        lan865x_mdio: lan865x_mdio {
            compatible = "microchip,lan865x-mdio";
            status = "okay";
            #address-cells = <1>;
            #size-cells = <0>;
            ethernet-phy@0 {
                compatible = "microchip,t1s-phy";
                reg = <0x0>;
                plca-enable;
                plca-node-id = <0>;
                plca-node-count = <8>;
                plca-burst-count = <0>;
                plca-burst-timer = <0x80>;
                plca-to-timer = <0x20>;
                status = "okay";
            };
        };
    };
};

decsny · 2025-01-31T14:35:57Z

Hi @decsny,

I was finaly able to make the lan865x work. The initialization seems succesful without any errors. However, at the moment I am not able to test it further.

BTW, something that I noticed: The maximal frequency that I could set is 2MHz. If the frequency was set higher, the SCK was unstable. But in any case It is great that the PR addressed also this issue 👍🏻

Will this PR be backported to v3.7 LTS?

MIMXRT1064_EVK Overlay:
&lpspi1 {
    status = "okay";
    transfer-delay=<200>;
    pcs-sck-delay=<100>;
    sck-pcs-delay=<100>;
    eth0: lan865x@0 {
        status = "okay";
        compatible = "microchip,lan865x";
        reg = <0>;
        int-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>; /* D9 */
        rst-gpios = <&gpio1 3 GPIO_ACTIVE_LOW>; /* D8 */
        local-mac-address = [ 00 19 05 00 00 04  ];
        spi-max-frequency = <2000000>;
        lan865x_mdio: lan865x_mdio {
            compatible = "microchip,lan865x-mdio";
            status = "okay";
            #address-cells = <1>;
            #size-cells = <0>;
            ethernet-phy@0 {
                compatible = "microchip,t1s-phy";
                reg = <0x0>;
                plca-enable;
                plca-node-id = <0>;
                plca-node-count = <8>;
                plca-burst-count = <0>;
                plca-burst-timer = <0x80>;
                plca-to-timer = <0x20>;
                status = "okay";
            };
        };
    };
};

It's not clear to me what fixed the issue for you, was it those two properties I mentioned, or that PR, Or the frequency being limited to 2 MHz? Or all of them together? We should make sure this is clear before considering this closed. Also, if the frequency has to be limited to 2 MHz, that still seems like another kind of bug

And no , sadly the PR probably cannot be justified for any backports, as it's not just that one PR but a collection, with thousands of lines of changes, and the driver completely rewritten from scratch... although technically it was all in pursuit of fixing bugs, I think release team would not allow it....

mariopaja · 2025-01-31T15:11:18Z

@decsny
Then I am reopening the issue and I will try to do some more tests limiting the frequency to 2MHz on v3.7 LTS since it is the branch where I noticed the issue and the branch of interest for us.

The frequency when set above 2MHz becomes unstable. The higher it is set the more it fluctuates.

decsny · 2025-01-31T15:18:07Z

The frequency when set above 2MHz becomes unstable. The higher it is set the more it fluctuates.

Is it possibly a sampling rate issue ?

lmajewski · 2025-01-31T15:19:04Z

@mariopaja @decsny - The reduction of SPI frequency to 2MHz seems to me like just papering over the real issue.

mariopaja · 2025-01-31T15:48:13Z

The frequency when set above 2MHz becomes unstable. The higher it is set the more it fluctuates.

Is it possibly a sampling rate issue ?

@decsny I doubt that, in such cases the measurement fails or I get an error.

In general I am not expecting to reach 20MHz clock frequency, because none of the other boards tested before did but it should reach a certain frequency and then be more or less stable.

As I remember, when set to 10MHZ I could see variations from 2MHz to 10MHz. This pushed me to lower the frequency.

decsny · 2025-01-31T16:01:13Z

Absolute maximum frequency of LPSPI on RT1064 is 30 MHz. This can be lower depending on the clock source provided to the peripheral, so maybe that is something to look at.

Otherwise, there should be no logical/software reason that the LPSPI generates an unstable clock, so only other thing I can think to check is all the electrical specifications of the LAN865 and RT1064 , and pinctrl settings.

mariopaja · 2025-01-31T16:14:17Z

@decsny what clock configuration/source changes would you recommend to test?

Were there changes on the clock sources between v3.7 & this PR?

As I remember on v3.7 the clock was more or less stable compared to now.

decsny · 2025-01-31T16:20:56Z

I'm still unclear what was the thing that fixed the issue here. There was no mention of a regression in SCK stability from 3.7 until now.

So far there are 3 variables here:

Timing properties from DT
PR fixing PCS
Reduced frequency

Can you please isolate each variable here and clarify which one(s) are actually having any effect

mariopaja · 2025-02-05T08:11:10Z

@decsny I did the following tests

PR w/o transfer-delay pcs-sck-delay sck-pcs-delay @ 2MHz - Failed
Stable 2MHz SPI Clock

&lpspi1 {
    status = "okay";
    eth0: lan865x@0 {
        status = "okay";
        compatible = "microchip,lan865x";
        reg = <0>;
        int-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>; /* D9 */
        rst-gpios = <&gpio1 3 GPIO_ACTIVE_LOW>; /* D8 */
        local-mac-address = [ 00 19 05 00 00 04  ];
        spi-max-frequency = <2000000>;
        lan865x_mdio: lan865x_mdio {
            compatible = "microchip,lan865x-mdio";
            status = "okay";
            #address-cells = <1>;
            #size-cells = <0>;
            ethernet-phy@0 {
                compatible = "microchip,t1s-phy";
                reg = <0x0>;
                plca-enable;
                plca-node-id = <0>;
                plca-node-count = <8>;
                plca-burst-count = <0>;
                plca-burst-timer = <0x80>;
                plca-to-timer = <0x20>;
                status = "okay";
            };
        };
    };
};

PR w/ transfer-delay pcs-sck-delay sck-pcs-delay @ 2MHz - Passed
Stable 2MHz SPI Clock

&lpspi1 {
    status = "okay";
    eth0: lan865x@0 {
        status = "okay";
        compatible = "microchip,lan865x";
        reg = <0>;
        int-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>; /* D9 */
        rst-gpios = <&gpio1 3 GPIO_ACTIVE_LOW>; /* D8 */
        local-mac-address = [ 00 19 05 00 00 04  ];
        spi-max-frequency = <2000000>;
        lan865x_mdio: lan865x_mdio {
            compatible = "microchip,lan865x-mdio";
            status = "okay";
            #address-cells = <1>;
            #size-cells = <0>;
            ethernet-phy@0 {
                compatible = "microchip,t1s-phy";
                reg = <0x0>;
                plca-enable;
                plca-node-id = <0>;
                plca-node-count = <8>;
                plca-burst-count = <0>;
                plca-burst-timer = <0x80>;
                plca-to-timer = <0x20>;
                status = "okay";
            };
        };
    };
};

PR w/ transfer-delay pcs-sck-delay sck-pcs-delay @ 10MHz - Passed
SPI Clock varies from 4 - 12MHz

&lpspi1 {
    status = "okay";
    eth0: lan865x@0 {
        status = "okay";
        compatible = "microchip,lan865x";
        reg = <0>;
        int-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>; /* D9 */
        rst-gpios = <&gpio1 3 GPIO_ACTIVE_LOW>; /* D8 */
        local-mac-address = [ 00 19 05 00 00 04  ];
        spi-max-frequency = <10000000>;
        lan865x_mdio: lan865x_mdio {
            compatible = "microchip,lan865x-mdio";
            status = "okay";
            #address-cells = <1>;
            #size-cells = <0>;
            ethernet-phy@0 {
                compatible = "microchip,t1s-phy";
                reg = <0x0>;
                plca-enable;
                plca-node-id = <0>;
                plca-node-count = <8>;
                plca-burst-count = <0>;
                plca-burst-timer = <0x80>;
                plca-to-timer = <0x20>;
                status = "okay";
            };
        };
    };
};

PR w/ transfer-delay pcs-sck-delay sck-pcs-delay @ 20MHz - Passed
SPI Clock drops to ca. ~4MHz

&lpspi1 {
    status = "okay";
    transfer-delay=<200>;
    pcs-sck-delay=<100>;
    sck-pcs-delay=<100>;
    eth0: lan865x@0 {
        status = "okay";
        compatible = "microchip,lan865x";
        reg = <0>;
        int-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>; /* D9 */
        rst-gpios = <&gpio1 3 GPIO_ACTIVE_LOW>; /* D8 */
        local-mac-address = [ 00 19 05 00 00 04  ];
        spi-max-frequency = <20000000>;
        lan865x_mdio: lan865x_mdio {
            compatible = "microchip,lan865x-mdio";
            status = "okay";
            #address-cells = <1>;
            #size-cells = <0>;
            ethernet-phy@0 {
                compatible = "microchip,t1s-phy";
                reg = <0x0>;
                plca-enable;
                plca-node-id = <0>;
                plca-node-count = <8>;
                plca-burst-count = <0>;
                plca-burst-timer = <0x80>;
                plca-to-timer = <0x20>;
                status = "okay";
            };
        };
    };
};

PR w/ transfer-delay pcs-sck-delay sck-pcs-delay @ 25MHz - Passed
SPI Clock drops to ca. ~4MHz

&lpspi1 {
    status = "okay";
    transfer-delay=<200>;
    pcs-sck-delay=<100>;
    sck-pcs-delay=<100>;
    eth0: lan865x@0 {
        status = "okay";
        compatible = "microchip,lan865x";
        reg = <0>;
        int-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>; /* D9 */
        rst-gpios = <&gpio1 3 GPIO_ACTIVE_LOW>; /* D8 */
        local-mac-address = [ 00 19 05 00 00 04  ];
        spi-max-frequency = <25000000>;
        lan865x_mdio: lan865x_mdio {
            compatible = "microchip,lan865x-mdio";
            status = "okay";
            #address-cells = <1>;
            #size-cells = <0>;
            ethernet-phy@0 {
                compatible = "microchip,t1s-phy";
                reg = <0x0>;
                plca-enable;
                plca-node-id = <0>;
                plca-node-count = <8>;
                plca-burst-count = <0>;
                plca-burst-timer = <0x80>;
                plca-to-timer = <0x20>;
                status = "okay";
            };
        };
    };
};

v3.7 failes in all the cases above

decsny · 2025-02-05T14:47:54Z

@mariopaja I'm assuming this is with current main?

It seems like the issue is resolved for the LAN functioning so maybe we can close this issue?

Except why is the SCK only 4 MHz when set otherwise ? is this another issue ? and does it only happen for the RT parts?

mariopaja · 2025-02-06T06:03:17Z

@decsny

I'm assuming this is with current main?

I was using #82877 for the tests.

It seems like the issue is resolved for the LAN functioning so maybe we can close this issue?

It seems like this PR has already addressed the issue seen on v3.7. I think we can close this issue.

Except why is the SCK only 4 MHz when set otherwise ? is this another issue ? and does it only happen for the RT parts?

The clock would be nice to know why it has such behaviour. However, I will try to do some more tests on RT parts but also on other MCUs. Afterwards, I might open onether issue addressing it

lmajewski · 2025-02-06T09:38:04Z

@mariopaja @decsny Just for the record - on STM32 based system - the SPI frequecy:
spi-max-frequency = <25000000>;
works fine with LAN865x devices.

I'm just concerned, that 2MHz is way too slow and there must have been issue with the NXP's SPI driver.

mariopaja · 2025-02-06T09:57:11Z

@lmajewski I will also do some more tests with u575 and rt1064 with other measurement devices to determine if the issue was the used logic analyser. I will also post the results in this issue and then open another issue just for the RT part SCK

mariopaja added the bug The issue is a bug, or the PR is fixing a bug label Mar 1, 2024

jukkar added the area: Ethernet label Mar 1, 2024

aescolar assigned decsny Mar 5, 2024

aescolar added the priority: low Low impact/importance bug label Mar 5, 2024

decsny added platform: NXP NXP and removed platform: NXP NXP labels Mar 5, 2024

mariopaja changed the title ~~drivers: ethernet: LAN865x inconsistent behaviour between different MCUs~~ drivers: ethernet: LAN865x not working with RT1170 & RT1064 Mar 13, 2024

mariopaja changed the title ~~drivers: ethernet: LAN865x not working with RT1170 & RT1064~~ LAN865x not working with RT1170 & RT1064 Mar 13, 2024

decsny added the platform: NXP NXP label Apr 13, 2024

github-actions bot added the Stale label Jun 13, 2024

dleach02 removed the Stale label Jun 24, 2024

decsny added area: SPI SPI bus platform: NXP Drivers NXP Semiconductors, drivers labels Jun 24, 2024

decsny changed the title ~~LAN865x not working with RT1170 & RT1064~~ LAN865x not working with RT1170 & RT1064 (likely caused by LPSPI issues) Jun 24, 2024

bperseghetti mentioned this issue Aug 23, 2024

Add rt1180 spi/edma support #77458

Merged

decsny removed the Stale label Nov 8, 2024

github-actions bot added the Stale label Jan 8, 2025

decsny removed the Stale label Jan 9, 2025

mariopaja closed this as completed Jan 31, 2025

mariopaja reopened this Jan 31, 2025

decsny mentioned this issue Feb 4, 2025

NXP LPSPI: Convert to native zephyr driver, remove MCUX shim #85010

Open

mariopaja closed this as completed Feb 9, 2025

mariopaja reopened this Feb 9, 2025

mariopaja closed this as completed Feb 9, 2025

LAN865x not working with RT1170 & RT1064 (likely caused by LPSPI issues) #69658

LAN865x not working with RT1170 & RT1064 (likely caused by LPSPI issues) #69658

Comments

mariopaja commented Mar 1, 2024 • edited Loading

aescolar commented Mar 5, 2024 • edited Loading

decsny commented Mar 5, 2024

lmajewski commented Mar 6, 2024

mariopaja commented Mar 6, 2024 • edited Loading

decsny commented Mar 6, 2024 • edited Loading

mariopaja commented Mar 13, 2024 • edited Loading

mariopaja commented Apr 10, 2024

mariopaja commented Apr 10, 2024 • edited Loading

mariopaja commented Apr 11, 2024

lmajewski commented Apr 12, 2024

mariopaja commented Apr 12, 2024

lmajewski commented Apr 12, 2024

github-actions bot commented Jun 13, 2024

decsny commented Jun 24, 2024 • edited Loading

github-actions bot commented Aug 24, 2024

github-actions bot commented Jan 8, 2025

mariopaja commented Jan 9, 2025

decsny commented Jan 9, 2025 • edited Loading

decsny commented Jan 29, 2025

mariopaja commented Jan 30, 2025

decsny commented Jan 30, 2025

decsny commented Jan 30, 2025

mariopaja commented Jan 31, 2025 • edited Loading

decsny commented Jan 31, 2025 • edited Loading

mariopaja commented Jan 31, 2025 • edited Loading

decsny commented Jan 31, 2025

lmajewski commented Jan 31, 2025

mariopaja commented Jan 31, 2025

decsny commented Jan 31, 2025

mariopaja commented Jan 31, 2025

decsny commented Jan 31, 2025 • edited Loading

mariopaja commented Feb 5, 2025 • edited Loading

decsny commented Feb 5, 2025

mariopaja commented Feb 6, 2025

lmajewski commented Feb 6, 2025

mariopaja commented Feb 6, 2025 • edited Loading

mariopaja commented Mar 1, 2024 •

edited

Loading

aescolar commented Mar 5, 2024 •

edited

Loading

mariopaja commented Mar 6, 2024 •

edited

Loading

decsny commented Mar 6, 2024 •

edited

Loading

mariopaja commented Mar 13, 2024 •

edited

Loading

mariopaja commented Apr 10, 2024 •

edited

Loading

decsny commented Jun 24, 2024 •

edited

Loading

decsny commented Jan 9, 2025 •

edited

Loading

mariopaja commented Jan 31, 2025 •

edited

Loading

decsny commented Jan 31, 2025 •

edited

Loading

mariopaja commented Jan 31, 2025 •

edited

Loading

decsny commented Jan 31, 2025 •

edited

Loading

mariopaja commented Feb 5, 2025 •

edited

Loading

mariopaja commented Feb 6, 2025 •

edited

Loading