STM32 SPI - wrong behavior after PR 34731

[Delsian]

McuBoot fails to read JEDEC ID over SPI:

[00:00:00.166,000] <err> spi_flash_at45: Wrong JEDEC ID: 00 1F 26, expected: 1F 26 00

This bug occurs after applying PR #34731
Commit hash 0129884
Removing this change solves the problem.

McuBoot settings:

...
CONFIG_FLASH=y
CONFIG_SPI=y
CONFIG_SPI_FLASH_AT45=y
...

SPI settings:

&spi1 {
	status = "okay";
	pinctrl-0 = <&spi1_nss_pa4 &spi1_sck_pa5
		     &spi1_miso_pa6 &spi1_mosi_pa7>;
};

Dataflash settings:

&spi1 {
	cs-gpios = <&gpioa 4 GPIO_ACTIVE_LOW>;

	dataflash0: at45db321e@0 {
		compatible = "atmel,at45";
		reset-gpios = <&gpioc 4 GPIO_ACTIVE_LOW>;
		wp-gpios = <&gpioa 3 GPIO_ACTIVE_LOW>;
		reg = <0>;
		spi-max-frequency = <1000000>;
		label = "DATAFLASH_0";
		jedec-id = [1f 26 00];
		size = <16777216>;
		sector-size = <65536>;
		block-size = <4096>;
		page-size = <512>;
		use-udpd;
		enter-dpd-delay = <1000>;
		exit-dpd-delay = <180000>;
	};
};

@galak @FRASTM @affrinpinhero-2356 FYI.
I did no more checks, just adding a patch locally to remove this PR from my project. Looks like #34731 breaks SPI RX functionality.
Also in my project some errors periodically occurs with mentioned PR:

[00:00:03.939,000] <err> spi_ll_stm32: spi_stm32_get_err: err=64
[00:00:03.943,000] <err> pl360_hw: SPI error -5

[00:00:04.735,000] <err> spi_ll_stm32: spi_stm32_get_err: err=64
[00:00:04.740,000] <err> pl360_hw: SPI error -5

[00:00:04.835,000] <err> spi_ll_stm32: spi_stm32_get_err: err=64
[00:00:04.840,000] <err> pl360_hw: SPI error -5

[00:00:05.141,000] <err> spi_ll_stm32: spi_stm32_get_err: err=64
[00:00:05.142,000] <err> pl360_hw: SPI error -5

[00:00:05.938,000] <err> spi_ll_stm32: spi_stm32_get_err: err=64
[00:00:05.942,000] <err> pl360_hw: SPI error -5

[00:00:07.129,000] <err> spi_ll_stm32: spi_stm32_get_err: err=64
[00:00:07.133,000] <err> pl360_hw: SPI error -5

[avisconti]

I also have an issue with commit 0129884. (Removing this commit everything works fine)
In my case I'm using Nucleo F401RE or F411RE with x_nucleo_iks02a1 or x_nucleo_iks01a3 shield. I did a modification to the samples to test both sensorhub and standard mode with mult-instance. The instance on DIL24 is attached thru SPI, and with this commit STM32 is not able to retrieve even sensor chip id.

I saved my branch on my github: iis2iclx-fix-triggers-multi-instance-test

[avisconti]

I just saw that same issue is happening on sensortile.box board using latest master. Again, if I remove 0129884 the SPI starts working again (by the way I have another issue on that board to STTS751 device, but it is on I2C, so totally different story)

with 0129884

0.003,000] <inf> HTS221: Cannot enable trigger without drdy-gpios
[00:00:00.003,000] <dbg> IIS3DHHC.iis3dhhc_spi_init: SPI GPIO CS configured on GPIOE:10
[00:00:00.004,000] <dbg> IIS3DHHC.iis3dhhc_init_chip: Invalid chip id 0xff
[00:00:00.004,000] <dbg> IIS3DHHC.iis3dhhc_init: Failed to initialize chip
[00:00:00.004,000] <dbg> LIS2DW12.lis2dw12_spi_init: SPI GPIO CS configured on GPIOE:11
[00:00:00.004,000] <err> LIS2DW12: Invalid chip ID
[00:00:00.004,000] <dbg> LIS2MDL.lis2mdl_spi_init: SPI GPIO CS configured on GPIOA:15
[00:00:00.004,000] <err> LIS2MDL: Invalid chip ID: 00
[00:00:00.005,000] <inf> LSM6DSO: Initialize device LSM6DSO
[00:00:00.005,000] <inf> LSM6DSO: chip id 0xff
[00:00:00.005,000] <dbg> LSM6DSO.lsm6dso_init_chip: Invalid chip id 0xff
[00:00:00.005,000] <dbg> LSM6DSO.lsm6dso_init: failed to initialize chip
[00:00:00.005,000] <wrn> usb_cdc_acm: Device not configured or suspended, drop 1 bytes
[00:00:00.106,000] <wrn> usb_cdc_acm: Device not configured or suspended, drop 1 bytes
[00:00:00.206,000] <wrn> usb_cdc_acm: Device not configured or suspended, drop 1 bytes
[00:00:00.306,000] <wrn> usb_cdc_acm: Device not configured or suspended, drop 1 bytes
[00:00:00.406,000] <wrn> usb_cdc_acm: Device not configured or suspended, drop 1 bytes
[00:00:00.505,000] <dbg> STTS751.stts751_init_chip: Failed reading chip id
[00:00:00.505,000] <dbg> STTS751.stts751_init: Failed to initialize chip
[00:00:00.506,000] <wrn> usb_cdc_acm: Device not configured or suspended, drop 1 bytes
[00:00:00.562,000] <inf> usb_cdc_acm: Device suspended
[00:00:00.976,000] <inf> usb_cdc_acm: Device configured
SensorTile.box test!!
Could not get LIS2DW12 device

without 0129884

0:00:00.003,000] <inf> HTS221: Cannot enable trigger without drdy-gpios
[00:00:00.003,000] <dbg> IIS3DHHC.iis3dhhc_spi_init: SPI GPIO CS configured on GPIOE:10
[00:00:00.004,000] <dbg> LIS2DW12.lis2dw12_spi_init: SPI GPIO CS configured on GPIOE:11
[00:00:00.004,000] <dbg> LIS2DW12.lis2dw12_set_power_mode: Apply default Power Mode
[00:00:00.005,000] <dbg> LIS2MDL.lis2mdl_spi_init: SPI GPIO CS configured on GPIOA:15
[00:00:00.007,000] <inf> LSM6DSO: Initialize device LSM6DSO
[00:00:00.007,000] <inf> LSM6DSO: chip id 0x6c
[00:00:00.509,000] <dbg> STTS751.stts751_init_chip: Failed reading chip id
[00:00:00.509,000] <dbg> STTS751.stts751_init: Failed to initialize chip
[00:00:00.565,000] <inf> usb_cdc_acm: Device suspended
[00:00:00.983,000] <inf> usb_cdc_acm: Device configured
SensorTile.box test!!
Could not get STTS751 device

You can find the sensortile.box sample here:
https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/boards/sensortile_box

board:
https://github.com/zephyrproject-rtos/zephyr/tree/main/boards/arm/sensortile_box

doc:
https://docs.zephyrproject.org/latest/boards/arm/sensortile_box/doc/index.html

[StefJar]

I am having problems with the stm32 spi as well. After migrating my fw from an older zephyr version to the latest main branch the SPI does not seem to work.
I checked the CS etc to make sure that everything is fine and setup.
It does not really matter if I am using the DMA or not. If no DMA is used I am getting spi_ll_stm32: spi_stm32_get_err: err=64.

My setup is:
two SPI slaves on my SPI3. They are setup with different speeds, SPI_MODE_CPOL and SPI_MODE_CPHA parameters. So the SPI driver needs to switch almost every time its config.

Happy to test quickly any changes on that issue.

@galak anyone working on that?

[erwango]

@galak anyone working on that?

Yes, we are.
(Hint: You can check the assignee field on top of each issue to see who's working on what)

[avisconti]

I am having problems with the stm32 spi as well. After migrating my fw from an older zephyr version to the latest main branch the SPI does not seem to work.
I checked the CS etc to make sure that everything is fine and setup.
It does not really matter if I am using the DMA or not. If no DMA is used I am getting spi_ll_stm32: spi_stm32_get_err: err=64.

My setup is:
two SPI slaves on my SPI3. They are setup with different speeds, SPI_MODE_CPOL and SPI_MODE_CPHA parameters. So the SPI driver needs to switch almost every time its config.

Happy to test quickly any changes on that issue.

@galak anyone working on that?

Can you try to check it again after a git revert 0129884 ?
Just to be sure that we are talking about same issue...

[StefJar]

I am having problems with the stm32 spi as well. After migrating my fw from an older zephyr version to the latest main branch the SPI does not seem to work.
I checked the CS etc to make sure that everything is fine and setup.
It does not really matter if I am using the DMA or not. If no DMA is used I am getting spi_ll_stm32: spi_stm32_get_err: err=64.
My setup is:
two SPI slaves on my SPI3. They are setup with different speeds, SPI_MODE_CPOL and SPI_MODE_CPHA parameters. So the SPI driver needs to switch almost every time its config.
Happy to test quickly any changes on that issue.
@galak anyone working on that?

Can you try to check it again after a git revert 0129884 ?
Just to be sure that we are talking about same issue...

Done the changes, but it seems to me that they don't have a real effect. Guess my issue is maybe different.