cancel
Showing results for 
Search instead for 
Did you mean: 

STM32MP157CA SPI1 Clock does not work

DBaes.1
Associate III

We use the STM32MP157CA and the STM32CubeIDE and let the code generator generate a confiuration with the required modules. In our case the SPI1 on the pins (PZ0,PZ1,PZ2). The generated functions provide the initializations for the SPI1. Unfortunately the SPI1 does not work for us in normal operation mode. If we call the HAL_SPI_Transmit(...) function after the initialization we get a SPI timeout. On the oscilloscope we see no clock on the spi clock line. We also noticed that when we use the engineering mode for the M4 the SPI1 works.

If we change the SPI to the SPI5 (also generated with the code generator) everything works in normal operation mode and in engineering mode. How can we use the SPI1 in normal operation mode on the M4?

18 REPLIES 18

Hi,

could you check that in your uBoot and kernel DT, you have this line?

#include "stm32mp15-m4-srm.dtsi"

This will include other file which contain important DT declaration for M4 assigned peripherals.

like this one https://github.com/STMicroelectronics/linux/blob/v5.10-stm32mp/arch/arm/boot/dts/stm32mp15-m4-srm.dtsi

Regards.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

Hello PatrickF,

i have check the uBoot and kernel DT. Both have the

#include "stm32mp15-m4-srm.dtsi

line.

But my console Message do not include the

[xxxx.xxxx] rproc-srm-core 10000000.m4:m4_system_resources: bound 10000000.m4:m4_system_resources:spi@44004000 (ops xxxx)

lines when i start the M4.

Mine look like this:

remoteproc remoteproc0: Booting fw image MP1M4-SP00261.elf, size 3542808
[  145.357067]  mlahb:m4@10000000#vdev0buffer: assigned reserved memory node vdev0buffer@10042000
[  145.367638] virtio_rpmsg_bus virtio0: rpmsg host is online
[  145.372194] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty-channel addr 0x0
[  145.380111]  mlahb:m4@10000000#vdev0buffer: registered virtio0 (type 7)
[  145.386751] rpmsg_tty virtio0.rpmsg-tty-channel.-1.0: new channel: 0x400 -> 0x0 : ttyRPMSG0
[  145.387483] remoteproc remoteproc0: remote processor m4 is now up
[  145.409260] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty-channel addr 0x1
[  145.419239] rpmsg_tty virtio0.rpmsg-tty-channel.-1.1: new channel: 0x401 -> 0x1 : ttyRPMSG1
[  145.435174] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty-channel addr 0x2
[  145.453165] rpmsg_tty virtio0.rpmsg-tty-channel.-1.2: new channel: 0x402 -> 0x2 : ttyRPMSG2

Only our 3 RPMSG channels are displayed as a message.

So, after M4 FW is started, when you enter:

cat /proc/device-tree/ahb/m4@10000000/m4_system_resources/spi@44004000/status

you probably get 'disabled'.

It is likely that the parsed kernel device tree miss the &m4_spi1 node.

Please double check if you compile and use the right device trees.

in uBoot log, you should have something like

Retrieving file: /stm32mp157c-xxxx.dtb

If not the expected file, please check extlinux.conf, not clear to me how it works for custom board, but for sure it could end up that Linux not using the right DT.

https://wiki.st.com/stm32mpu/wiki/How_to_compile_the_device_tree_with_the_Developer_Package#Updating_extlinux

Regards.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

Hello PatrickF,

i check the spi1 status when the M4 is running wih:

cat /proc/device-tree/mlahb/m4@10000000/m4_system_resources/spi@44004000/status

and get "okay".

Yes our custom dtb gets loaded at boot.

To check the device tree i copy the kernel device tree from /boot and "decompile" the dtb with:

dtc -I dtb -O dts -o decompiled.dts stm32mp157c-hp00164.dtb

The dts contains entries for spi@4400400:

/ {
...
soc {
        ...
        spi@44004000 {
			#address-cells = <0x01>;
			#size-cells = <0x00>;
			compatible = "st,stm32h7-spi";
			reg = <0x44004000 0x400>;
			interrupts = <0x00 0x23 0x04>;
			clocks = <0x01 0x82>;
			resets = <0x01 0x4c48>;
			dmas = <0x0c 0x25 0x400 0x01 0x0c 0x26 0x400 0x01>;
			dma-names = "rx\0tx";
			power-domains = <0x0d>;
			status = "disabled";
		};
...
}
...
mlahb {
        ...
        m4@10000000 {
                ...
                m4_system_resources {
                         ...
			spi@44004000 {
					compatible = "rproc-srm-dev";
					reg = <0x44004000 0x400>;
					clocks = <0x01 0x82>;
					status = "okay";
					pinctrl-names = "default";
					pinctrl-0 = <0x5e>;
				};
                       ...
              }
    ...
     }
}

Hi,

could you also check if

cat /proc/device-tree/ahb/m4@10000000/m4_system_resources/status

return 'okay' too ?

In case you rebuilt the kernel, please check if the following config are enabled (they are ON by default in the starter package):

  • REMOTEPROC_SRM_DEV
  • REMOTEPROC_SRM_CORE

Regards.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

Hello PatrickF,

i check the m4_system_resurces status with:

cat /proc/device-tree/mlahb/m4@10000000/m4_system_resources/status

but it returns "disabled" when the M4 is running.

I also check the config for my actual running kernel with:

cat /proc/config.gz | gunzip > running.config
vi running.config

for the Remoteproc drivers i have set:

#
# Remoteproc drivers
#
CONFIG_REMOTEPROC=y
CONFIG_REMOTEPROC_SRM_CORE=y
CONFIG_REMOTEPROC_SRM_DEV=y
CONFIG_STM32_RPROC=y

Best regards.

So, as the following command

    cat /proc/device-tree/mlahb/m4@10000000/m4_system_resources/status

return 'disabled', you certainly have somewhere in your kernel DT an overwrite of the status = "okay"; below (which is required)

&m4_rproc {
    	m4_system_resources {
    		status = "okay";
    	};
};

Please check the order of DT includes as only last values set are taken into account.

As your are using ByteEngine SOM DT, maybe worth to talk to them.

Regards.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

Hello PatrickF,

after we managed to enable the m4_system_resources the SPI1 clock works with PLL3_Q.

Thanks for your help.

Best regards.

Hi,

nice to see it was finally working.

Regards.

In order to give better visibility on the answered topics, please click on 'Select as Best' on the reply which solved your issue or answered your question. See also 'Best Answers'

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.