I want to control an I2C bus on Cortex-M7 side.
I saw that i2C_1 is available on X20 (pins 6,7) but it looks very busy (used by Torizon OS apparently)
I2C_3 could also be available on X19 (pins 19,20) but this need to review R343/R344/R345/R346 arrangement to re- route pins for I2C instead of CAM.
Is there any other usage of I2C_3 that I should be aware of ?
Can I switch R343/R344 0 Ohms resistors to R345/R346 in order to route I2C_3 on X19 without any other effects ?
Alternatively, is there a way to use I2C on cortex-M7 side without having Torizon OS running on A53 ? I
Software summary
------------------------------------------------------------
Bootloader: U-Boot
Kernel version: 5.15.129-6.5.0+git.6f8fd49366db #1-TorizonCore SMP PREEMPT Fri Dec 22 11:15:52 UTC 2023
Kernel command line: root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/fe091cbe7b665ff6d9d5d618cb20c42c90c242fffeaceccf204eacd186b2f597/0
Distro name: NAME="TorizonCore"
Distro version: VERSION_ID=6.5.0-build.8
Distro variant: VARIANT="Docker"
Hostname: verdin-imx8mp-15229850
------------------------------------------------------------
Hardware info
------------------------------------------------------------
HW model: Toradex Verdin iMX8M Plus WB on Verdin Development Board
Toradex version: 0058 V1.1B
Serial number: 15229850
Processor arch: aarch64
------------------------------------------------------------
[Configuration]
------------------------------------------------------------
Verdin iMX8M Plus Evaluation Kit with Touchscreen
with:
SOM i.MX8M Plus Quad 4GB WB IT v1.1B
Dahlia Carrier Board v1.1D
Verdin DSI to LVDS rev 1.1A
Capacitive Touch Display 10.1" v1.0A
I’m trying to test i2c bus usage with i2c_interrupt_b2b_transfer_master.c from SDK_2_15_000_MIMX8ML8xxxKZ. This code was initially developed for an NXP evaluation board with i2c_3 bus which is not wired on the Dalhia board, see below:
I’m using MCUXpresso extension on VSCode, SEGGER J-Link debugging probe and a Beagle i2c spying tool.
The i2c b2b transfer test code is downloaded into M7, I see it running but up to now, no sign of activity on the i2c bus.
Remark: before downloading the test code, i stopped the A53 linux boot at U-Boot level by pressing “space” during boot following the Cortex-M Jtag debugging method : Cortex-M JTAG Debugging | Toradex Developer Center.
Should I use i2c_4 (AKA SOM_CAM_1) on Dahlia board, or can I enable i2c_3 by placing zero ohm resistors R345, R346 ?
Can anything else prevent i2c from working ?
I2C_4 could be used by the CSI camera control and I2C_3 by HDMI Display Data Channel. If you want to use the specific I2C on Cortex-M7 side, it is recommended to disable it from Linux via Device Tree (Device Tree topic is out of scope of our discussion here and you can read more here or look up in our community on how to do that).
That means, you have to choose to sacrifice one of the features mentioned above on the Linux side. And yes, in this way Torizon OS (Linux) won’t manage/interfere with the I2C usage on Cortex-M7.
These are some documentation we have on the topic:
I was completing my previous question while you were responding. Linux is not running (stopped at U-Boot level).
Do I still need to review Device tree ? And i yes can you provide me with one example on how to do so ?
Remark: I do not understand how the same pins 19/20 on X19 are labelled i2c_3 (with R345 and R346) and i2c_4 (with R343 and R344)…
as far as I know, if Linux is not running, then everything should be is fine. As soon as Linux is booting, it will use the Device Tree to initialize the peripherals and if Linux uses any peripheral used by Cortex-M7, it will take the ownership of the peripheral from the Cortex-M7. (I think it is possible to share a peripheral for both Cortex-A and Cortex-M but I am familiar about that and it would be complex to avoid concurrent access from both execution context → better to address NXP about this if you are interested).
How did you “change for I2C_1”? Did you redefine the pinmuxing (BOARD_InitPins function) in pin_mux.c? I assume as long as Linux is not running, you are free to use any I2C. Yes, if you want to use I2C_3 you should pay R345 & R346 but you should remove the ones for I2C_4.
The numbering of the peripherals is quite confusing, since there are numbering from NXP (on SoC level) and on module level (Verdin spec). If I see correctly, the pinmuxing given in the i2c example on the MCUXpresso SDK is already correctly setup (it is using IOMUXC_I2C3_SCL_I2C3_SCL and IOMUXC_I2C3_SDA_I2C3_SDA macro) to output the signal on I2C_4_CSI_SDA/SDL lines (the one already connected by default on pin 19 and 20 on X19). Try the unmodified sample and see if you can see any activity on the bus used by Cortex-M.
As you said, even if there are several slaves on this i2c bus, if Linux is not running, I should see activity coming from M7 side. So far I don’t.
I do see activity when Linux is running, but not with M7 alone.
did you try to use the SDK example “as is” (which is using I2C_3)? I expect that the example should just works “out-of-the-box” via pin 19 & 20 on X19 header. It should work before Linux starts
Yes I did !
I didn’t yet changed the resistors arrangement, but I was expecting to get some bus activity on left side of R345/R346. So far no activity.
According to Verdin datasheet, i2c_3 is available on pins 57 (SDA) and 59 (SCL) of sodimm connector X1.
I checked by my self electrical continuity between X1/57 , X1/59 and -not placed- R345/R346: it’s ok despite the fact that R11 resistors array is not on the drawing.
We can now ascertain that the issue is not hardware.
I still think there is some misunderstanding about the I2C naming and the problem is with the pin muxing. The output should come from Dahlia I2C_4_CSI_SDA/SDL line via default R343 and R344 resistors (you don’t need to do any soldering or desoldering work). The connection you should be using are as below:
If you use the default pinmuxing given by MCUXpresso SDK, you should find the signal output from SODIMM 93 and 95 (I2C control lines meant for CSI camera):
I’ve got a signal on X19 19/20 !!
My bad, when turning back from i2c_1 to i2c_3, the search/replace I made was not correct.
there was some remains of i2c_3 in the pinmux…
happy to hear that and honestly, I would have run out of idea if it still didn’t work
I think the next step for you would be to get both core domains to talk with each other via rpmsg/remoteproc. Again, refer to our documentation and also have a look in the other community threads if you are stuck.
