cancel
Showing results for 
Search instead for 
Did you mean: 

Enable I2C peripheral in coprocessor

thareeq
Associate

Hi, I am working with the STM32MP25 and trying to use the I2C peripheral from the Cortex-M33 coprocessor.

The STM32MP25 includes an Arm Cortex-A35 core running Linux and a Cortex-M33 core for real-time applications. I am able to successfully load and run a basic firmware on the Cortex-M33 using remoteproc. However, when I enable and initialize the I2C peripheral in the M33 firmware, the system hangs and eventually restarts. After investigating, I learned that the RIFSC configuration must be updated to grant the Cortex-M33 access to the I2C peripheral. I applied a patch to modify the RIFSC settings accordingly, but the issue persists and the peripheral is still not accessible from the M33.

I would like to know:

Are there any additional steps required (beyond RIFSC configuration) to allow Cortex-M33 access to I2C?

Is there official documentation or reference material explaining how to properly assign peripherals to the coprocessor using RIFSC?

Are there any examples or recommended workflows for enabling peripherals for M33 in a Linux + RTOS environment on STM32MP25?

Any guidance on best practices or relevant documentation would be greatly appreciated

2 REPLIES 2
raksha1
Associate II

I'm stuck in the same problem, please email me [email removed by moderation] if you figured it out.

I work on stm32mp257f-dk, currently running openstlinux starter package on A35 and trying to run mpu6050 with zephyr rtos on M33.

**Trying to run mpu6050 sample code:**
- Hardware:
pin 1 / - / 3.3v
pin3 / pz3 / sda
pin5 / pz4 / scl
pin6 / - / GND
----
- Software:
we added ~/zephyrproject/zephyr/samples/sensor/mpu6050/boards/stm32mp257f_dk_stm32mp257fxx_m33.overlay because trying to build without it results in an error -> stm32mp257f_dk_stm32mp257fxx_m33.overlay is misssing

&i2c8 {
    status = "okay";

    mpu6050: mpu6050@68 {
        compatible = "invensense,mpu6050";
        reg = <0x68>;
    };
}


Then we built the sample and did the same as before from the "scp" to the "echo start > state" only to be faced with this error while probing the ttyACM1:

***** BUS FAULT *****
  Precise data bus error
  BFAR Address: 0x46040000
r0/a1:  0x00000000  r1/a2:  0x00000000  r2/a3:  0xffffffff
r3/a4:  0xffffffff r12/ip:  0x0000ad00 r14/lr:  0x80102355
xpsr:  0x69000000
Faulting instruction address (r15/pc): 0x80102354


we didn't really understand what the error talks about and we kept guessing.
- first, we checked the hardware connections several times and we made sure it is valid.
- then we noticed that the "BFAR Address: 0x46040000" refers to the address of the i2c8 (verified in the devicetree) so we rechecked our DeviceTree overlay and the i2c8 nodes in the boards device tree for any missing spec, nothing suspicious.
- This was gibberish for us to be honest 
"r0/a1:  0x00000000  r1/a2:  0x00000000  r2/a3:  0xffffffff
    r3/a4:  0xffffffff r12/ip:  0x0000ad00 r14/lr:  0x80102355"
- and finaly, we saw " xpsr:  0x69000000 ", i thought to my self maybe "69" refers to the mpu6050 address expected so we added the another connector connecting AD0 to GND to force it to the address 0x68, same error, then we modified the devicetree to "mpu6050@69" and "reg = <0x69>;" and connected the AD0 to 3.3v, same error

 

 

raksha1
Associate II

I found the problem,
it is important to say that i'm using zephyr rtos for the m33 part so maybe the solution would be a little different for you.
in zephyr i found that the device trees (.dts and .dtsi) of my board dosen't allow the gpioz (status = "disabled")
so in addition to initializing the i2c8 node you need to do the same for its corresponding gpio, i2c8 being in gpioz

&i2c8 {
    status = "okay";

    bmp388: bmp388@76{
        compatible = "bosch,bmp388";
        reg = <0x76>;
    };
};

&gpioz {
	status = "okay";
};