Using the LPSPI driver on MCXA156 with the generic "jedec,spi-nor" driver and a external flash memory only works with optimizations disabled

[ehughes]

I am tracking an obscure bug with the shim based driver for LPSPI on the MCXA156. Even though the LPSPI driver passes the spi loopback test, I was able to get it to fail when using it with real devices.

Setup:

I have a FRDM-MCXA156 with a W25q64 SPI Flash memory wired to LPSPI1.

I am using the "spi_flash" sample as a basis for the my test.

Note: As a control, I also tested the same flash chip wired to a FRDM-MCX947 (which also uses LPSPI) and a LPC55S69Xpresso (which has flexcomm). The spi_flash sample runs OK on both of them. I narrowed it down to some interaction w/ the MCXA156 / LPSPI

I created an overlay :

The nor flash driver driver works through boot and most of the test. It can read the the JEDEC flash ID, issue erase commands, etc. However, I noticed that writes would fail. After some debugging I observed this on my logic analyzer:

The specific transaction for the flash write had the chip select active >200mS, most of that idle. The transaction after that was a command to shut down the flash as the SPI transaction for the write returned a timeout from the driver.

The flash write is successful if all optimizations are disabled.

Looking through the spi_nor driver and LPSPI Flash driver, I found this:

If you follow the spi_transcieve_dt function:

I noticed when optimizations are on, This if statement never evaluates to true. (Using Segger Ozone to single step and evaluate)

With optimizations off, it will evaluate to true for the write transcations.

This does appear to be timing related. If I turn on the SPI log dbg messages, the sample will work.

I noticed that MCXN driver instance had a fifo size of 8 while MCXA had a size of 4. If I reduce this size, the MCXA156 version works

Values of 1,2,3 yield a successful result with optimizations enabled. A value of 4 (the dts default) will result in the timeout error.

Let me know if there is a test I can run, etc.

• OS: Windows
• Toolchain : zephyr-sdk-0.17.0
• Commit : 491bbcf

[ehughes]

Testing Update

@decsny mentioned he had trouble with the the jedec,nor driver and lpspi on the FRDM-MCXW71. The FRDM-MCXW71 has a 8-pin NOR SPI flash populated on the board (MX25L6406E) and is connected to lpspi1.

The W71 has LPSPI like the MCXA. However in the SOC dtsi, the properties tx-fifo-size and rx-fifo-size are set to to 8. This isthe same as the MCX N LPSPI instanace.

The spi_flash driver works with the default fifo sizes on this platform (no timeout errors). It's LPSPI instance appears to be the same the the MCX N (which also work). However, it does require a different change to function correctly that I also noticed with the MCXA LPSPI driver.

Overlay used for the frdm-w71:

&lpspi1 {
	status = "okay";
	pinctrl-0 = <&pinmux_lpspi1>;
	pinctrl-names = "default";

	transfer-delay=<500>;

	MX25L6406E@0 {
		compatible = "jedec,spi-nor";
		size = <0x4000000>;	// 64 Mbits 
		reg = <0>;
		spi-max-frequency = <1000000>;
		jedec-id = [c2 28 17];
		status = "okay";
	};	
};

&pinctrl
{
  	pinmux_lpspi1: pinmux_lpspi1 {
		group0 {
			pinmux = <LPSPI1_SIN_PTB1>,
					<LPSPI1_PCS0_PTB0>,
					<LPSPI1_SCK_PTB2>,
					<LPSPI1_SOUT_PTB3>;
			slew-rate = "fast";
			drive-strength = "low";
			input-enable;
		};
	};

};

Note the override for the transfer-delay. The LPSPI driver defaults to a minimal allowed value. However, this leads to SPI clock waveforms that have a very narrow pulse in between byte transacation. In the case of the macronix part on the W71, there will be errors in the data.

https://media.discordapp.net/attachments/1328777237717061703/1335992831390515261/image.png?ex=67a22fc8&is=67a0de48&hm=b8a8f2483fdf0b7e6bd3c04136bf6fd05a8a3d92e91c11816c6ad268fa6a516a&=&format=webp&quality=lossless&width=1440&height=554

For the purpose of my test, I set it to a value that would yield a 50% duty cycle

Without this change, the nor driver will report a mistach between the JEDEC IDs.

Note

This is not root cause to the original issue with the timeout error, just something I came across. I think the transfer delay should default to a value that will always yield a 50% duty clk as it is the safest options for most SPI peripherals.

(I can open up another issue if needed).

Summary for LPSPI tests with the SPI_FLASH sample:

1.) MCXA156 - I get the timeout error on some SPI transactions when optimization are working. The fix is to override the tx/rx fifo size to 1,2 or 3 (default of 4).

2. ) MCXN947 - Works OK out of the box using the same flash chip as the A156. It's default tx/rx fifo size is 8

3.) FRDM-MCXW71 - This has an onboard spi nor device that is similar to #1. Does not show the timeout issue but the trasnfer-delay needs to be adjust so the SPI clk has a reasonable duty cycle.

4.) LPC55S69Xpresso - This is a control test as it uses flexcomm spi drivers. This uses the same externally wired SPI flash as #1 and #2. No issues. spi_flash sample works OK.

[decsny]

@ehughes thanks for the tip about MCXW71, I changed the transfer-delay to just be the SCK period and that fixed the issue I was having. PR is here #85189 for that

[decsny]

@ehughes I tried to look into this issue today , but realized I don't have the hardware to do it. I will have to find some board with this flash (or any spi flash) to connect to the frdm mcxa156 board.

With that said though, can you please try again on latest main (or 4.1.0 release), because I think since you made this report I have added some code in the interrupt handler to resolve (or at least mitigate) some race conditions and make it more robust.

Also, in the future, please for the items in the bug report that help with reproduce, such as overlays and config files, please put them as text instead of screenshot.

[ehughes]

@decsny

I tried testing this today. Unfortunately there is busfault occuring early in the startup process:

I think this is the same issue as #87768

[decsny]

@decsny

I tried testing this today. Unfortunately there is busfault occuring early in the startup process:

I think this is the same issue as #87768

Can you try testing on 4.1 release, it's much more stable and has the fixes I mentioned, current main branch is a bit of a mess

[decsny]

@ehughes main branch is much more stable now, even better than 4.1, I would try it again