SPE I2C app fail

Dear Sir,

I am trying the SPE apps on a Jetson Xavier NX, I am using JetPack 5.1.2 on this board.

I download the SPE source package from https://developer.nvidia.com/downloads/embedded/l4t/r35_release_v4.1/sources/spe-freertos-bsp.tbz2/, and build it to T194 binary (make bin_t19x) and documents (make docs) successfully.

I follow up the guideline of documents which built by command “make docs”, and try the app Timer and IVC successfully on Jetson Xavier NX.

When I try the I2C app on Jetson Xavier NX with following steps:

  1. Update the dtsi file Linux_for_Tegra/sources/hardware/nvidia/platform/t19x/galen/kernel-dts/common/tegra194-audio-p2822-0000.dtsi as below:
    i2c@c250000 {
    status = “disabled”;
    rt5658: rt5659.7-001a@1a {
    compatible = “realtek,rt5658”;
    reg = <0x1a>;

                     /* refer include/sound/rt5659.h for the values to be used */
                     realtek,jd-src = <0>; /* RT5659_JD_NULL */
                     realtek,dmic1-data-pin = <0>; /* RT5659_DMIC1_NULL */
                     realtek,dmic2-data-pin = <1>; /* RT5659_DMIC2_DATA_IN2P */
    
                     gpios = <&tegra_main_gpio TEGRA194_MAIN_GPIO(S, 5) 0>;
    
                     status = "disabled";
    
                     /*
                     port {
                             rt5658_ep: endpoint {
                                     remote-endpoint = <&i2s1_dap_ep>;
                                     mclk-fs = <256>;
                                     link-name = "rt565x-playback";
                             };
                     };
                     */
             };
     };
    
  2. Build the new DTB files, copy all the built DTB files to ${L4T}/kernel/dtb;

  3. In SPE source tree soc/t19x/target_specific.mk, set ENABLE_SPI_APP := 1 and rebuild the application;

  4. Copy the generated spe.bin to ${L4T}/bootloader/spe_t194.bin;

  5. Flash all the paritions including new DTB files and SPE binaries generated from the above steps into Xavier NX with command “sudo ./flash.sh jetson-xavier-nx-devkit mmcblk0p1”.

After the new firmware is flashed into Jetson Xavier NX successfully, I power off the Xavier NX, connect the I2C device to Xavier NX (pin 1, 3, 5, 39 of 40 pin header), and then, power on the Xavier NX.

Unfortunately, when the Xavier NX reboots, there is no “I2C test successful” printed out, I trace this issue in the soc/t19x/src/i2c-app-priv.c, print out the return value and data read from I2C which get by API i2c_do_transfer(), this API call in function i2c_test returns -150994946.

What’s wrong in the steps I try the I2C app on Xavier NX?

Thanks,

Best Regards,
George

tegra194-audio-p2822-0000.zip (2.5 KB)

The updated tegra194-audio-p2822-0000.dtsi is attached for your reference.

Hello,
Sorry that I noticed you change the option ENABLE_SPI_APP := 1 , do you mean I2C or SPI?

I guess that’s a typo.

For I2C, you can check the waveform of I2C pins first, to confirm whether the settings take effect. Also, you can add some print code in SPE firmware to confirm the desired routine is called.

br
ChenJian

Yes, you are right, it is a typo, the option “ENABLE_I2C_APP := 1” is correct.

I added some debug codes in the soc/t19x/src/i2c-app-priv.c, and find that the return value from function i2c_do_transfer() is -150994946.

Is it possible that the I2C PINs (1, 3, 5, 39 of 40 pin header) which I am using are not on the AO domain?

Pin 3, 5 are not in AO cluster. Pin 1 and 39 are power and GND pins, not I2C pins. You can get the power domain of the pins referring to the pinmux sheet.
Jetson Xavier NX Pinmux Table

Thanks, just for double check, I learn from above “Jetson Xavier NX Pinmux Table”, the only I2C in AO domain is 185 & 187, so, only this PIN could be used in SPE, am I right?

Are 185 & 187 linked to 27 & 28 of 40 pin header on P3509 carrier board?

Hello,
You can take a look at Xavier TRM.
Following three I2C controllers are accessible from SPE.
I2C10 0x0c230000 0x0c23ffff SYSTEM
I2C2 0x0c240000 0x0c24ffff SYSTEM
I2C8 0x0c250000 0x0c25ffff SYSTEM

You can find a spare one for test.

br
ChenJian

Hi, may I learn from you about the pins of I2C 2, 8, 10 on NX SoC?

I attach the I2C device to pin 27,28 of 40 pin header on the carrier board, the device could be found on the bus “i2c-1 i2c c240000.i2c I2C adapter” in JetPack OS.

After that, I update the tegra194-soc-cvm.dtsi to disable i2c@c240000, rebuild the DTB files for Tegra194.
I modify the soc/t19x/config/config.h too, update the I2C_AON_BUS_NUM to 2, rebuild the SPE binary (bin_t19x) and copy the generated spe.bin to booloader/spe_t194.bin.
I flash all the paritions including new DTB files and SPE binaries generated from the above steps into Xavier NX with command “sudo ./flash.sh jetson-xavier-nx-devkit mmcblk0p1”.

After the new firmware is flashed into Jetson Xavier NX successfully, when the Xavier NX reboots, I2C test still fail, same the return value from API i2c_do_transfer(), this API call in function i2c_test returns -150994946.

tegra194.zip (2.6 KB)
The updated config.h and tegra194-soc-cvm.dtsi are attached for your reference.

Hello,
Sorry that I’ve not tested same case as you’ve done.
Here are some debug tips.

  1. In Linux side, run some commands like i2cget, etc., to confirm the pins are good, with good communication from I2C device. It’s better to check the waveform with scope as well.

  2. When 1 is good, disable the corresponding I2C controller in Linux side, and go forward to SPE side. For driver side, you can add some print code and confirm the register (based c240000) is accessible from I2C driver in SPE. Then check the waveform.
    If register access is good but no waveform in pins, it may be due to wrong setting of pinmux.

Also, you can track what the error value returned means.
I2C demo in Xavier NX is not a ready demo program, and it may need more efforts to make it work.

br
Chenjian

Hi,

  1. In Linux side, I try to use command ‘i2cdetect -r -y 1’ to detect the device on this bus, and the attached device is listed by this command; atfer that, I use command ‘i2cdump -f -y 1 0x68’ to dump data from attached device, and I get expected data. I would think this I2C device is attached to right pins, the pins are good, and the system communicate with attached I2C device well.

  2. I disable the I2C controller in Linux side by updating the tegra194-soc-cvm.dtsi, and update soc/t19x/config/config.h to use right I2C bus, I do not know if I do this correct, so that I attach the updated files to you for a double check. But the result is not expected, I do not know what wrong I made or some steps I missed, so that I ask help from you.

I am sorry I do not know the meaning of unexpected return value -150994946 from i2c_do_transfer(), I could not find any description/document about this function, hopefully I could learn from you where to find the description about this function.

Thanks,

Best Regards,
George

Hello,

  1. For Linux side, you can dump the kernel DTB in running time.
    dtc -I fs -O dts -o local.dts /proc/device-tree

And check output local.dts, i2c@c240000, the status should be disabled.

  1. For SPE side, have you got other log from UART? If i2c_do_transfer fails, some other error message may appear.
    Have you ever confirmed that the I2C registers @c240000 can be accessed from SPE?
    You can track into the driver code in SPE firmware for details.

br
Chenjian

Hi,

  1. the I2C bus i2c@c240000 is disabled, I could find the status of i2c@c240000 in the dts file which generated by command "dtc -I fs -O dts -o local.dts /proc/device-tree“ is disabled, and in the JetPack OS environment, the bus i2c@c240000 is not detected and listed by the command ‘i2cdetect -l’; the local.dts is attached for you reference.
    local_dts.zip (57.4 KB)

  2. There is no more error message from UART excepts the debug outputs which added by me.

    Have you ever confirmed that the I2C registers @c240000 can be accessed from SPE?
    You can track into the driver code in SPE firmware for details.

    May I learn from you to track into the driver code in SPE firmware?

Best Regards,
George

Hello,

  1. kernel dtb looks good, and c240000 is disabled in kernel side.
  2. For register accessing, you can add some code in “fsp/source/drivers/i2c/i2c-tegra.c” to dump the register read/write message to confirm the register-level access from SPE R5 is good.
  3. Please use scope to check the I2C clock pin, and when access is on-going, you should see the clock waveform. If not, maybe pinmux is not configured correctly, or the pins are wrong.

br
Chenjian

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.