stm32 SPI problems with DMA and INTR set-up

[StefJar]

I on my stm32f412 discovered that a SPI3 config related issues.

1st) the rx and tx dma channel must be the same
2nd) the comms to my lsm6ds3 sensor only works when the DMA and INTR config is disabled

my board dts:

// activate spi3 to access the LSM6DS3 and ADS1292
&spi3 {
	pinctrl-0 = <&sensor_clk &sensor_miso &sensor_mosi>;
	
	// chip select
	// 0: PC9 -> MOV_SS
	// 1: PB5 -> EEG_ADC_SS
    cs-gpios = <&gpioc 9 GPIO_ACTIVE_LOW>, <&gpiob 5 GPIO_ACTIVE_LOW>;
    
	// spi3 tx stream 5 on channel 0
	// spi3 rx stream 2 on channel 0
	dmas = <&dma1 5 0 0x440 0x03>, <&dma1 2 0 0x480 0x03>;
	dma-names = "tx", "rx";
    
	status = "okay";
	
	lsm6ds3: lsm6ds3@0 {
		compatible = "st,lsm6ds3";
		label = "LSM6DS3";
		reg = <0>;
		spi-max-frequency = <10000000>;
		// PC8 MOV interrupt 1 (MOV_INT1)
		// PA8 MOV interrupt 2 (MOV_INT2)
		int1-gpios = <&gpioc 8 GPIO_ACTIVE_HIGH>;
		int2-gpios = <&gpioa 8 GPIO_ACTIVE_HIGH>;
	};

	ads1292: ads1292@1 {
		compatible = "ti,ads1292";
		label = "ADS1292";
		reg = <1>;
		spi-max-frequency = <2048000>;
		// PB4 EEG data ready (EEG_ADC_DRDY)
		drdy-gpios = <&gpiob 4 GPIO_ACTIVE_HIGH>;
	};
};

the config

CONFIG_SPI=y
# CONFIG_SPI_STM32_INTERRUPT=y
# CONFIG_SPI_STM32_DMA=y
# CONFIG_SPI_ASYNC=y

As said the interrupt and/or dma option breaks my code. Means that the transfer to lsm6ds3 fails. Also the transfer to ads1292 fails from time to time.

When using different DMA channels the SPI driver complains with:
<err> dma_stm32: dma stream 0 is busy.
Any idea why only same dma channels for rx&tx are working?

[erwango]

@StefJar I'm moving this issue as "question" until we're able to prove the issue actually lies in the driver.
We'll try to analyse your point meanwhile.

[StefJar]

@erwango I am talking about 2 issues related to spi via DMA and ISRs. Maybe you know someone with a F412 demo board. This person can prove the DMA channel issue. Maybe the other issue is related to that as well.

For me it feels, that the spi3 config (polarity, clk rate, etc.) is not proper changed between the DMA transfers/ISR processes.

At my full set up the uart3 and spi3 are both using the DMA for their rx/tx. The uart code is still marked experimental(I am using the ASYNC option). So maybe there is some undetected issue as well.

[erwango]

@StefJar Would you be able to test you set up using differential testing

• Test SPI independantly (UART3 disabled, or DMA disabled on UART3)
• Disable ISR/DMA one at a time on SPI
  Btw, if you're using only one SPI instance, you shouldn't need to enable both SPI_STM32_DMA and SPI_STM32_INTERRUPT at the same time. It should be possible to enable both but only one could be used at a time on a single instance.

For reference, I've been able to do basic testing on a nucleo_f411re using DMA=y, ISR=y and DMA+ISR.
This was done using SPI_1, but I don't expect instance to have an influence.
Cf tests/drivers/spi/spi_loopback/boards/nucleo_f411re.overlay for dma configuration.

[StefJar]

I you check the "nucleo_f411re.overlay" you will see that the dma channel for rx and tx is the same. So pls change them to maybe 3 and 2 and confirm that it generates the stream busy message.
One thing I saw when copying the dma setup was that some flags where not proper set. The 411 setup was not working for me. So I altered it to:

	// spi1 tx stream 3 on channel 3
	// spi1 rx stream 0 on channel 3
	dmas = <&dma2 3 3 0x440 0x03>, <&dma2 0 3 0x480 0x03>;

0x28440 -> 0x440
0x28480 -> 0x480

Maybe here lies a mistake from my side

[erwango]

I you check the "nucleo_f411re.overlay" you will see that the dma channel for rx and tx is the same. So pls change them to maybe 3 and 2 and confirm that it generates the stream busy message.

I've tried the following successfully:

&spi1 {
	dmas = <&dma2 2 2 0x28440 0x03
		&dma2 0 3 0x28480 0x03>;
	dma-names = "tx", "rx";
};

[StefJar]

0x440 vs 0x28440 = Bit15 and Bit16-17 are different
Bit15 translates to:
0 - offset size is linked to the peripheral bus width
1 - offset size is fixed to 4 (32-bit alignment)
B16 translates to: Priority level
00 - low
10 - high

I am understanding the priority level
But can you pls tell me why rx and tx should be always aligned to 32Bit? To my knowledge we are streaming an array of bytes which may be not aligned to 32Bit addr offsets

[erwango]

But can you pls tell me why rx and tx should be always aligned to 32Bit? To my knowledge we are streaming an array of bytes which may be not aligned to 32Bit addr offsets

Why do you say this "should be always aligned to 32Bit" ?
This is configuration option, so you should be able to change it. I can't swear this has been validated with all combinations, but at least code supports different settings.

[StefJar]

Ok cool. My stuff is working with the test DMA settings. So I think my problem is not related to that. Guess we can rule out the DMA channel setup.
Now it comes down to the problem, that the SPI transfers are not working with DMA & ISRs enabled, when having more than one device attached. Do you may have the possibly to check SPI transfers while switching between different devices (different CPOL & CLK + CS)?
I debugged into the CS code. It works the same no matter what "mode"(DMA or not) we are on. Maybe some MCU reg needs some handling after dma(+isr) transfers?

[erwango]

Now it comes down to the problem, that the SPI transfers are not working with DMA & ISRs enabled, when having more than one device attached. Do you may have the possibly to check SPI transfers while switching between different devices (different CPOL & CLK + CS)?

This still not clear to me why you enable both DMA and ISR if you only have one SPI device enabled.
A SPI device (SPI3 in your case) can only work with one for a specific build.
DMA and ISR might be enabled in case you have several SPI devices and you want to hndle them in different ways (eg ISR on SPI_1 and DMA on SPI3).

This being said, can you have a try using only DMA ? Then only ISR ?

[StefJar]

I done the requested tests:

• test spi independently (uart3 dma disabled at uart3 node)
• disable/enable isr/dma at spi3

results:
[UART3 dma=off, SPI INTR=on, SPI DMA=off] = works
[UART3 dma=off, SPI INTR=off, SPI DMA=on] = fail
[UART3 dma=on, SPI INTR=on, SPI DMA=off] = works
[UART3 dma=on, SPI INTR=off, SPI DMA=on] = fail

Fail = SPI only reads from ads1292 device but not from lsm6ds3.

[erwango]

Thanks for these tests!

Just to be sure, can you provide the configuration you're using for UART3? This would be surprising there's a conflict since you mention this is working with ads1292, but who knows ?

If there is no conflict, it would mean that we're having a specific issue to alternate reads on 2 devices when using DMA, while this is working with IRQ..

[StefJar]

yep sure

// bc127 con via uart3
&usart3 {
	pinctrl-0 = <&bc127_tx &bc127_rx &bc127_rts &bc127_cts>;

	// uart3 tx stream 4 on channel 7
	// uart3 rx stream 1 on channel 4
	dmas = <&dma1 4 7 0x28440 0x03>, <&dma1 1 4 0x28480 0x03>;
	dma-names = "tx", "rx";

	current-speed = <115200>;

	status = "okay";
};

plus

CONFIG_SERIAL=y
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_UART_ASYNC_API=y

all my tests went against the latest main branch (6e2522d)

I will quickly drop the device config here
ads1292

	ads1292.spi_conf.frequency = DT_PROP(ADS1292_DTS_NODE_INST, spi_max_frequency); // 2.048MHz clk speed
	ads1292.spi_conf.operation = (SPI_OP_MODE_MASTER | SPI_TRANSFER_MSB | SPI_MODE_CPHA | SPI_WORD_SET(8) | SPI_LINES_SINGLE);
	ads1292.spi_conf.slave = DT_REG_ADDR(ADS1292_DTS_NODE_INST); // slave number 0
	ads1292.spi_conf.cs = &ads1292.spi_cs_conf;

lsm6ds3

	lsm6ds3.spi_conf.frequency = DT_PROP(LSM6DS3_DTS_NODE_INST, spi_max_frequency); // 10MHz clk speed
	lsm6ds3.spi_conf.operation = (SPI_OP_MODE_MASTER | SPI_TRANSFER_MSB | SPI_MODE_CPOL | SPI_MODE_CPHA | SPI_WORD_SET(8) | SPI_LINES_SINGLE);
	lsm6ds3.spi_conf.slave = DT_REG_ADDR(LSM6DS3_DTS_NODE_INST); // slave number 0
	lsm6ds3.spi_conf.cs = &lsm6ds3.spi_cs_conf;

[avisconti]

@StefJar
Just jumping in and trying to figure out what is happening...
First of all I don't see lsm6ds3 supported in main branch, so I'm guessing that is driver that you wrote correct?
(BTW, that's good, as I didn't have in my plan to develop it, as it is an old IMU, overseeded by LSM6DSx new components).

Why are you using both int1 and int2? Are you putting drdy on int1 and some other event on int2?
Then I have another doubt. I see that int1 is configured on PC8 while int2 on PA8 gpios. But is it even possible to do that without getting a "busy" error? If I remember well, interrupts are shared among gpio ports on the pin basis (correct me if I do not remember correctly). So PA8 and PC8 should result in conflict.

Can you also give me some hints on how you are testing it on F412 nucleo? I would like to try to replicate it as well without too much wiring... Thanks!

[avisconti]

Sorry, I clicked on "close" by mistake.

[StefJar]

@avisconti

I don't have a nucleo F412 only a pcb(of the headphones my company is doing) where I attach my programmer/debugger.

I wrote a driver for the lsm6ds3 and the ads1292. They are on the same spi3 bus. These driver are not really generic. I am using my own dts binding for them. In the lsm6ds3 case you can have 2 signal lines. They are connected at the pcb and so they are connected at the dts. At the firmware only one signal is used.
The spi3 read goes in that way. If the ADS1292 signals that there is a new sample we do a read. After we check if there is an sample of the lsm6ds3. This needs to be done in that way because there is a bug at the ADS1292. It translates into the pattern, that you need to read the ads1292 sample before the lsm6ds3. This is not the problem of the failed DMA transfers.
I am happy to send the drivers over to you to speed you up :D

[avisconti]

@avisconti

I don't have a nucleo F412 only a pcb(of the headphones my company is doing) where I attach my programmer/debugger.

I wrote a driver for the lsm6ds3 and the ads1292. They are on the same spi3 bus. These driver are not really generic. I am using my own dts binding for them. In the lsm6ds3 case you can have 2 signal lines. They are connected at the pcb and so they are connected at the dts. At the firmware only one signal is used.
The spi3 read goes in that way. If the ADS1292 signals that there is a new sample we do a read. After we check if there is an sample of the lsm6ds3. This needs to be done in that way because there is a bug at the ADS1292. It translates into the pattern, that you need to read the ads1292 sample before the lsm6ds3. This is not the problem of the failed DMA transfers.
I am happy to send the drivers over to you to speed you up :D

I reminded now that I have a sensortile.box board supported by zephyr working well which has already multiple devices on spi1 bus. I can try to replicate the issue on it. So, if my understanding is correct, I would need to enable the dma in the DT (which is a good thing anyway) and make sure that the channel is the same one for tx and rx streams. Is it correct?

[StefJar]

@avisconti yes that should do.

CONFIG_SPI=y
# CONFIG_SPI_STM32_INTERRUPT=y
CONFIG_SPI_STM32_DMA=y
# CONFIG_SPI_ASYNC=y

Best would be if your sensortile.box board has at least 2 sensors at the same spiX bus. Ideally both sensors have different bus clks and polarity etc. Just to make sure that the MCU switches the spi_config rightfully. Here I can rule out the spi_config changes as root cause for the DMA problem.
Good luck and let me know if I can support you :)

[avisconti]

@avisconti yes that should do.

CONFIG_SPI=y
# CONFIG_SPI_STM32_INTERRUPT=y
CONFIG_SPI_STM32_DMA=y
# CONFIG_SPI_ASYNC=y

Best would be if your sensortile.box board has at least 2 sensors at the same spiX bus. Ideally both sensors have different bus clks and polarity etc. Just to make sure that the MCU switches the spi_config rightfully. Here I can rule out the spi_config changes as root cause for the DMA problem.
Good luck and let me know if I can support you :)

Have you tried to raise the dma priority (e.g. using 0x20440 and 0x20480)?

[avisconti]

I'm not able to get it working. Can you give me your git repo branch that will take a look?

[StefJar]

I tried 0x440 and 0x480. Same issue. Guess it's not related to DMA channel prio.

The whole sensing stuff is embedded into a bigger firmware. So I have my doubts that cutting stuff out there this will help you.
I attach the drivers + hw api. its the spi3 you are looking for ;)

st32SPI3fail.zip