nxp: lpspi: regression accessing spi flash

[sgfeniex]

Describe the bug

Recent changes in the LPSPI driver #93523 have broken communications with a SPI Flash device on my custom board.

[00:00:00.071,000] <err> littlefs: can't open flash area 1, err -19
[00:00:00.071,000] <err> fs: fs mount error (-19)
[00:00:00.071,000] <err> littlefs: Automount /lfs2 failed: -19

Regression

• This is a regression.

Steps to reproduce

Configure a spi nor flash on lpspi

Relevant log output

[00:00:00.071,000] <err> littlefs: can't open flash area 1, err -19
[00:00:00.071,000] <err> fs: fs mount error (-19)
[00:00:00.071,000] <err> littlefs: Automount /lfs2 failed: -19

Impact

Major – Severely degrades functionality; workaround is difficult or unavailable.

Environment

OS: Ubuntu
Toolchain: Zephyr SDK 0.17
Zephyr main
Processor: MIMXRT1062
Peripheral: LPSPI4

Additional Context

I bisected to this commit:

commit 860f9c8 (HEAD)
Author: Martin Stumpf finomnis@gmail.com
Date: Tue Jul 22 17:40:20 2025 +0200

spi_nxp_lpspi: Fix underflow in lpspi sck calculation

If `desired_delay_ns` is `0`, it is much saner to set the delay to `0x00`
than to underflow and set it to `0xff`, which is the current behavior.

Signed-off-by: Martin Stumpf <finomnis@gmail.com>

❯ git bisect log
# bad: [8e5e9922c5c428d457568e317256894efccce078] Bluetooth: ISO: Fix sonarcloud issues in valid_chan_qos
# good: [413b789deb391d3a37d06b463288a5fe765ee57e] release: Zephyr v4.2.0
git bisect start 'HEAD' 'v4.2.0'
# good: [d9395d8502f6010455483f9ba775c330555d132f] net: lwm2m: json: Check for int64_t overflow when parsing integer
git bisect good d9395d8502f6010455483f9ba775c330555d132f
# bad: [814ed6803f329b5d8ca151e21ae25cddd9b143c5] tests: fix arm_irq_vector_table fail on Ambiq platforms
git bisect bad 814ed6803f329b5d8ca151e21ae25cddd9b143c5
# bad: [321ccb8889358cfd3e9f4c4f2b125d4142417951] led_strip: ws2812_spi: place buffer in __nocache for DMA
git bisect bad 321ccb8889358cfd3e9f4c4f2b125d4142417951
# bad: [b6b7b6759d020885ed9934ba91bf35b41e65af31] include: zephyr: dt-bindings: clock: stm32mp13_clock
git bisect bad b6b7b6759d020885ed9934ba91bf35b41e65af31
# bad: [b90cb5b773e8c49c140fb57791c306692d71eab5] maintainer: hal_nxp: align names to new management process
git bisect bad b90cb5b773e8c49c140fb57791c306692d71eab5
# good: [b633f3a9de85ac97ab5693b04ad8c08b3e90e113] net: lwm2m: Verify pmin for updated resource on notify check
git bisect good b633f3a9de85ac97ab5693b04ad8c08b3e90e113
# bad: [e5988398e37d9fe6f84c56faa498a85e829e81d3] doc: coding guidelines: add reference to MSC01-C for rule 15.7
git bisect bad e5988398e37d9fe6f84c56faa498a85e829e81d3
# good: [be38568577cd760d506b081b6de1bbe2a71c2a05] net: openthread: Fix build with CONFIG_OPENTHREAD_INTERFACE_EARLY_UP
git bisect good be38568577cd760d506b081b6de1bbe2a71c2a05
# bad: [64131856199342d0cb6507e5c57355c82f24dd69] drivers: flash: nordic: fix nrf-mramc indentation
git bisect bad 64131856199342d0cb6507e5c57355c82f24dd69
# bad: [860f9c8ef58766842229375300754f13e8181137] spi_nxp_lpspi: Fix underflow in lpspi sck calculation
git bisect bad 860f9c8ef58766842229375300754f13e8181137
# first bad commit: [860f9c8ef58766842229375300754f13e8181137] spi_nxp_lpspi: Fix underflow in lpspi sck calculation

I have confirmed that removing delay_cycles = MAX(delay_cycles, min_cycles); results in desired operation.

See related symptoms in #91015 but a different cause.

[sgfeniex]

Additional information while debugging.

I find that dev->CCR is set to 8 with Martin's fix. Prior to that commit, it is 4294967048 (0xffffff08).
The devicetree is configured like:

config_flash: &lpspi4 {
	status = "okay";
	pinctrl-0 = <&pinmux_lpspi4>;
	pinctrl-names = "default";
	cs-gpios = < &gpio2 20 GPIO_ACTIVE_LOW >;
	is25lp064_1: is25lp064_1@0 {
		compatible = "issi,is25lp064", "jedec,spi-nor";
		size = <DT_SIZE_M(8)>;
		status = "okay";
		jedec-id = [9d 60 17];
		reg = <0>;
		spi-max-frequency = <50000000>;
		wp-gpios = < &gpio2 18 GPIO_ACTIVE_LOW >;
		hold-gpios = < &gpio2 27 GPIO_ACTIVE_LOW >;
		
		partitions {
			compatible = "fixed-partitions";
			#address-cells = <1>;
			#size-cells = <1>;
			partition@0 {
				label = "big";
				reg = <0x00000000 DT_SIZE_M(8)>;
			};
		};
	};
};

I have tried with spi-max-frequency as low as 12MHz and still failed to communicate with this chip.

pcs-sck-delay, sck-pcs-delay, transfer-delay are not set on my platform. Is this something we need to characterize on a per-board basis?

Setting them like:

	transfer-delay = <10>;
	sck-pcs-delay = <10>;
	pcs-sck-delay = <10>;

results in success. There may be no issue with 860f9c8 after all.

[decsny]

@sgfeniex yes you need to set these values pcs-sck-delay, sck-pcs-delay, transfer-delay properly. Otherwise you might have communication issues. This is driven by the spi flash datasheet, look there for what to set it to. It's a bit weird to be setting slave properties on the controller node though, which is why I have this RFC here: #87427

If setting those values fixes for you, then we can close this issue

[decsny]

@Finomnis interesting how a bug can be a blessing by mistake sometimes, but think your commit is good, no issue here

[Finomnis]

Lol

[sgfeniex]

This is not an issue, and the values I ended up using are 8, 6, and 6.

6 from /CS setup and hold and 8 from output valid. Closing.

[ofirshe]

Hi @decsny and @Finomnis,

I have a device running at 20 MHz, and when I comment out the following line:
delay_cycles = MAX(delay_cycles, min_cycles);

communication works fine. However, with this commit, I’m seeing many communication errors with the device.
Here’s my device tree declaration:

&lpspi1 {
	status = "okay";
	pinctrl-0 = <&pinmux_lpspi1>;
	pinctrl-names = "default";
	/delete-property/ dmas;
	/delete-property/ dma-names;

	/*
	 * The field 'transfer-delay' should be half of
	 * the bus frequency to ensure a 50% duty cycle
	 * throughout the entire transaction.
	 */
	transfer-delay = <25>;

	si5402: si5402@0 {
		compatible = "skyworks,si5402";
		status = "okay";
		spi-max-frequency = <20000000>;
		reg = <0>;
	};
};

And the bus configuration for this device:
SPI_WORD_SET(8) | SPI_OP_MODE_MASTER | SPI_TRANSFER_MSB

Could you help me understand what in this commit might be causing the communication errors with my setup?

[Finomnis]

@ofirshe

Spi has three configurable delays:

• chip select to first clock
• last clock to chip select high
• between transfers

All three of them were accidentally set to maximum, reducing spi to a crippling low speed.
This change fixes that and sets them back to an appropriate value, with the default being zero.

Of your chip cannot handle zero delay, you need to add those three lines to your device tree node:

	transfer-delay = <something>;
	sck-pcs-delay = <something>;
	pcs-sck-delay = <something>; 

The values should be specified in the chip's reference manual.