Clock of lpspi6 has wrong duty-cycle

[cstoidner]

Hello, 

we have a problem with the lpspi6 clock on the i.MX 93. When we measure the clock signal with an oscilloscope, we can see that the high-level phase and low-level phase have different lengths. The low-level takes about 66% of the period, and the high-level only 33% of the period (see attached image 'SPI6_QuickPrint60.png'). 

We observed that behaviour with NXP BSP version "6.6.52_2.2.0". We measured the lpspi6 clock also with the older BSP version "6.1.55_2.2.0". With that older version we see that the clock signal behaves as we would expect it (50% high and 50% low).

Unfurtunately, with that wrong duty-cycle of version "6.6.52_2.2.0" we miss the limits of the spec of the connected SPI slave.

Find below the snippet from our DTS that enables/configures the lpspi6:

// ...

&lpspi6 {
   pinctrl-names = "default";
   pinctrl-0 = <&pinctrl_lpspi6>;
   cs-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
   status = "okay";

   /* TPM */
   tpm@0 {
      compatible = "infineon,slb9670", "tcg,tpm_tis-spi";
      reg = <0>;
      spi-max-frequency = <10000000>;
   };
};

// ...

pinctrl_lpspi6: lpspi6grp {
   fsl,pins = <
      MX93_PAD_GPIO_IO00__GPIO2_IO00 0x3fe
      MX93_PAD_GPIO_IO01__LPSPI6_SIN 0x3fe
      MX93_PAD_GPIO_IO02__LPSPI6_SOUT 0x3fe
      MX93_PAD_GPIO_IO03__LPSPI6_SCK 0x3fe
   >;
};

// ...

Do you have any idea which impact the software can have to the duty-cycle of the lpspi6 clock?
Do you have any idea how we can narrow down the problem?

Thanks,
Christoph

[Chavira]

Hi @cstoidner!

Thank you for contacting NXP Support!

What board are you using?

Are you using the A1 silicon version of the chip?

The issue is happening only with device that you are connecting?

Can you try using the spidev test?

Best Regards!

Chavira

[cstoidner]

Hi @Chavira  ,

> What board are you using?

We have our own custom board.

>Are you using the A1 silicon version of the chip?

Yes, we have rev A1.

> The issue is happening only with device that you are connecting?

I can not answer that, as we have only that device connected. However, what I can say is, that it seems to be somehow related to the software BSP version:

• In the past, we used NXP BSP version 6.1.55_2.2.0. With that, the spi clock duty-cycle was 50%/50%, as we would expect it.
• When we updated to NXP BSP version 6.6.23-2.0.0, we saw this wrong spi clock duty-cylce of 33%/66% for the first time.
• Also with the current latest BSP version 6.6.52_2.2.0 this wrong spi clock duty-cylce of 33%/66% occurs.

> Can you try using the spidev test?

The spi slave we have connected is a TPM (Trusted Platform Module) chip. So we just used the shell command

tpm2_getrandom --hex 32

on the board, to have some spi communication for measuring the clock signal.
Do you think "spidev test" would make any difference for the clock?

Thanks,
Christoph

[Chavira]

Hi @cstoidner!

I am using the FRDM-iMX93 board and I can´t replicate the issue (see the attached image).

The issue is only happening in LPSPI6?

[cstoidner]

Hi @Chavira ,

we tested it also on lpspi1. We had no slave connected, but during the tpm request from the imx93 we can see the clock. It is also other than expected (about 61% low and 39% high).

Any clue what can impact the SPI clock's duty cycle?

Regards,
Christoph

[Chavira]

Hi @cstoidner!

I think the problem should be your board or your custom driver since I can´t see that error in NXP boards.

Please check carefully and compare your results with our boards.

Best Regards!

Chavira

[cstoidner]

Hello @Chavira ,

I was going to test the problem on the NXP i.MX93 EVK. But I failed to boot the latest NXP BSP (Linux 6.6.52_2.2.0) on my EVK. I know that the EVK has the A0 revision of the i.MX93 SOM, so I changed the imx-boot recipe to use the A0 container ("mx93a0-ahab-container.img").

See my patch below:

diff --git a/meta-imx-bsp/recipes-bsp/imx-mkimage/imx-boot_1.0.bb b/meta-imx-bsp/recipes-bsp/imx-mkimage/imx-boot_1.0.bb
index cd42d16b4f..8a10bdab81 100644
--- a/meta-imx-bsp/recipes-bsp/imx-mkimage/imx-boot_1.0.bb
+++ b/meta-imx-bsp/recipes-bsp/imx-mkimage/imx-boot_1.0.bb
@@ -165,6 +165,7 @@ compile_mx93() {
cp ${DEPLOY_DIR_IMAGE}/${ddr_firmware} ${BOOT_STAGING}
done

+ cp ${S}/../mx93a0-ahab-container.img ${BOOT_STAGING}/
cp ${DEPLOY_DIR_IMAGE}/${SECO_FIRMWARE_NAME} ${BOOT_STAGING}/
cp ${DEPLOY_DIR_IMAGE}/${ATF_MACHINE_NAME} ${BOOT_STAGING}/bl31.bin
cp ${DEPLOY_DIR_IMAGE}/${UBOOT_NAME_EXTRA} ${BOOT_STAGING}/u-boot.bin
diff --git a/meta-imx-bsp/recipes-bsp/imx-mkimage/imx-boot_1.0.bbappend b/meta-imx-bsp/recipes-bsp/imx-mkimage/imx-boot_1.0.bbappend
index a68dbfd5ad..57edf81ec8 100644
--- a/meta-imx-bsp/recipes-bsp/imx-mkimage/imx-boot_1.0.bbappend
+++ b/meta-imx-bsp/recipes-bsp/imx-mkimage/imx-boot_1.0.bbappend
@@ -1,6 +1,10 @@
# Copyright 2017-2022 NXP
FILESEXTRAPATHS:prepend := "${THISDIR}/files:"

+SRC_URI += " file://mx93a0-ahab-container.img "
+
IMX_M4_DEMOS = ""
IMX_M4_DEMOS:mx8-nxp-bsp = "imx-m4-demos:do_deploy"
IMX_M4_DEMOS:mx8m-nxp-bsp = ""

And I also set:
     REV_OPTION="REV=A0"
in my loca.config

However I can only see u-boot SPL and BL31 starting on the serial console:

U-Boot SPL 2024.04-lf_v2024.04+g6c4545203d1+p0 (Nov 15 2024 - 04:02:13 +0000)
SOC: 0xa0009300
LC: 0x40010
PMIC: PCA9451A
PMIC: Over Drive Voltage Mode
Error: ele_volt_change_start_req: ret -5, response 0xf429
Error: ele_volt_change_finish_req: ret -5, response 0xf429
DDR: 3733MTS
M33 prepare ok
Normal Boot
Trying to boot from BOOTROM
Boot Stage: Primary boot
image offset 0x8000, pagesize 0x200, ivt offset 0x0
Load image from 0x50000 by ROM_API
NOTICE: TRDC init done
NOTICE: BL31: v2.10.0 (release):android-15.0.0_1.0.0-rc3
NOTICE: BL31: Built : 08:52:12, Nov 4 2024

After that the SOC stops to boot.

Do you have any clue whats going wrong? Can you explain me how to use the current NXP BSPs on the i.MX 93 EVK? Or is there a chance to get the EVK replaced with one that has the A1 SOC revision?

Thanks and regards,
Christoph