Other Parts Discussed in Thread: TCA6408
QNX/Blackberry delivers a BSP for the TI EVM. Depending on the TI EVM in use, in some case customers may want to enable additional I2C buses for access from A72 QNX.
How can this be done?
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Using the J721S2 EVM as an example, the below steps go over where to find information and areas to check when enabling support for another I2C bus instance on QNX. Similar steps can be followed for the TI family of devices.
Take a look at what is working
The case of the J721S2 EVM, there is a BSP provided by QNX that has a functional I2C0 driver, which can be seen the TI SDK QNX install at
The below line(s) are used to start the I2C0 bus for QNX on the A72:
A similar entry would need to be added for a different I2C bus to be supported. Let's use I2C4 as an example.
The I2C driver provided by QNX in the BSP provides for command line options for configuration of the I2C IRQ (above example is 232) and I2C address (above example is 0x0200_0000). By launching another instance of the driver, with different command line parameters another instance of the I2C H/W module can be supported. The TRM can be checked for base address and interrupt to be used.
I2C Instance Base Address and I2C Interrupt in TRM
The I2C module instance base address and interrupt number that need to be used on the command line are defined in the device TRM. In the J721S2 EVM example case being followed, the TRM is available at TDA4VL-Q1 data sheet, product information and support | TI.com.
Focusing on the I2C modules in the Main Domain, in the TRM reference:
Section 2.1: Main Memory Map (note that I2C4 maps to 0x0204_0000)
Section 9.4.8 Interrupt Sources -> GIC (note that I2C maps to IRQ 204)
Command for I2C
Based on the TRM information, the command to launch the driver for I2C4 on the J721S2 EVM would be:
Why 236? The working driver for I2C0 (IRQ 200) which is included in the QNX BSP, added 32 to the IRQ number, so same approach is followed.
For details on the i2c-omap35xx, make use of the 'use' command on the target:
J721S2-EVM@QNX:/# use i2c-omap35xx
OMAP35xx I2C manager
i2c-omap35xx [options]
Options:
-a addr Own address (default: 1)
-p addr I2C base address (default: 0x48070000)
-P prio priority of interrupt event pulse
-i irq I2C interrupt (default: 56)
-s slave Slave address (default: 0x49)
-v verbose
-f don't treat ROVR and XUDF as errors
-d don't pre-fill transmit FIFO, fill FIFO after transfer is started
-h value optional value to add to SCCH to adjust high clock period (value is in NS) (default=0)
-l value optional value to add to SCCL to adjust low clock period (value is in NS) (default=0)
J721S2-EVM@QNX:/#
How to Test?
To test the command on a J721S2 EVM, we'll need to know an address on the I2C bus, and what registers at that address can be read. The EVM User Guide ( https://www.ti.com/lit/ug/spruj69/spruj69.pdf ) shows that there is a GPIO expander at 0x20.
On the target read some bytes from the TCA6408 IO Expander (https://www.ti.com/lit/ds/symlink/tca6408a.pdf )
J721S2-EVM@QNX:/# isendrecv -n /dev/i2c4 -a0x20 -l1 0x0 data: 0h Data recvd: 0h J721S2-EVM@QNX:/# isendrecv -n /dev/i2c4 -a0x20 -l1 0x1 data: 1h Data recvd: ffh J721S2-EVM@QNX:/# isendrecv -n /dev/i2c4 -a0x20 -l1 0x2 data: 2h Data recvd: 0h J721S2-EVM@QNX:/# isendrecv -n /dev/i2c4 -a0x20 -l1 0x3 data: 3h Data recvd: ffh
If reads are not working some other items that could be checked:
Check that I2C4 is clocked and powered:
J721S2-EVM@QNX:/# k3conf dump clocks | grep I2C4 | 157 | 2 | DEV_BOARD0_I2C4_SCL_OUT | CLK_STATE_READY | 0 | | 157 | 249 | DEV_BOARD0_I2C4_SCL_IN | CLK_STATE_READY | 0 | | 218 | 0 | DEV_I2C4_PORSCL | CLK_STATE_READY | 0 | | 218 | 1 | DEV_I2C4_PISYS_CLK | CLK_STATE_READY | 96000000 | | 218 | 2 | DEV_I2C4_CLK | CLK_STATE_READY | 125000000 | | 218 | 3 | DEV_I2C4_PISCL | CLK_STATE_READY | 0 | J721S2-EVM@QNX:/# k3conf dump device | grep I2C4 | 218 | J721S2_DEV_I2C4 | DEVICE_STATE_ON |
Ensure that pad configuration is correct:
EVM schematics show AF28 -> I2C4_SDA, AD25 -> I2C4_SCL
Datasheet shows:
Referencing J721S2 TRM Registers:
Read back on target:
J721S2-EVM@QNX:/# k3conf read 0x0011c010 |------------------------------------------------------------------------------| | VERSION INFO | |------------------------------------------------------------------------------| | K3CONF | QNX (version 0.1-nogit built Tue Apr 9 12:54:54 PDT 2024) | | SoC | J721S2 SR1.0 | | SYSFW | ABI: 3.1 (firmware version 0x0009 '9.1.2--v09.01.02 (Kool Koala))') | |------------------------------------------------------------------------------| Value at addr 0x11c010 = 0x40008 J721S2-EVM@QNX:/# k3conf read 0x0011c014 |------------------------------------------------------------------------------| | VERSION INFO | |------------------------------------------------------------------------------| | K3CONF | QNX (version 0.1-nogit built Tue Apr 9 12:54:54 PDT 2024) | | SoC | J721S2 SR1.0 | | SYSFW | ABI: 3.1 (firmware version 0x0009 '9.1.2--v09.01.02 (Kool Koala))') | |------------------------------------------------------------------------------|
Ensure I2C4 is not being controlled elsewhere in the system
Only one core on the device can control I2C4 H/W module instance. If the A72 is going to be controlling the I2C4, then the R5s cannot be running anything on that bus in parallel.