CAN Transceiver Enable Control via IO Expander on Verdin i.MX95 EVK (Board Revision V1.3)

siddharthav · March 6, 2026, 4:52am

Hello Team,

We are currently working with the Toradex Verdin i.MX95 EVK (Board Revision V1.3) and are trying to enable the onboard CAN interfaces.

From the device tree and board documentation, we understand that the CAN transceivers (TJA1463) are controlled through an I²C-connected GPIO expander (PCAL6524). Specifically, the CAN transceiver EN and STB signals appear to be controlled through GPIO lines from this expander.

However, the board documentation does not clearly describe which PCAL6524 pins are connected to the CAN transceiver EN and STB signals.

Currently we observe the following behavior:

The FlexCAN driver loads correctly.
CAN interfaces can0 and can1 are created.
Internal loopback mode works as expected.
When loopback is disabled, CAN frames are not transmitted/received externally.
The CAN controller enters ERROR-PASSIVE state, suggesting that the transceiver may not be enabled.

Based on the device tree configuration, we suspect that the CAN transceivers are not being properly enabled through the IO expander.

We would like clarification on the following points:

Which PCAL6524 GPIO pins control the EN and STB signals of the CAN1 and CAN2 transceivers?
Are there any required patches, BSP configurations, or device tree settings needed to properly enable the CAN transceivers on the Verdin i.MX95 EVK?
Are there any example device tree configurations or reference implementations available for enabling CAN on this platform?

Any guidance or reference documentation would be greatly appreciated.

Here is our observation for I2C and CAN Tansreciever:

root@imx95-19x19-verdin:~# i2cdetect -y 2

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f

00:  -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --        

 

root@imx95-19x19-verdin:~# dmesg | grep -E "adp5585|2-0034"

[    1.909642] adp5585 2-0034: error -EIO: Failed to read device ID

[    1.915488] adp5585 2-0034: probe with driver adp5585 failed with error -5

[    2.030339] adp5585 1-0034: error -EIO: Failed to read device ID

[    2.036146] adp5585 1-0034: probe with driver adp5585 failed with error -5

[   19.713186] platform regulator-hmisc-vddio: deferred probe pending: platform: supplier 2-0034 not ready

[   19.722588] platform regulator-avdd: deferred probe pending: platform: supplier 2-0034 not ready

[   19.731412] platform regulator-vddo: deferred probe pending: platform: supplier 2-0034 not ready

[   19.740211] platform regulator-dvdd: deferred probe pending: platform: supplier 2-0034 not ready


root@imx95-19x19-verdin:~# cat /sys/kernel/debug/regulator/regulator_summary | grep -A 5 "can"

can1-en                          0    1      0 unknown  3300mV     0mA  3300mV  3300mV 

    can1-stby                     0    0      0 unknown  3300mV     0mA  3300mV  3300mV 

can2-en                          0    1      0 unknown  3300mV     0mA  3300mV  3300mV 

    can2-stby                     0    1      0 unknown  3300mV     0mA  3300mV  3300mV 

       425b0000.can-xceiver       0                                 0mA     0mV     0mV

USB_VBUS                         1    1      0 unknown  5000mV     0mA  5000mV  5000mV 

    4c200000.usb-vbus             1                                 0mA     0mV     0mV

aqr-stby                         1    1      0 unknown  3300mV     0mA  3300mV  3300mV 

    aqr-en                        1    1      0 unknown  3300mV     0mA  3300mV  3300mV 

       0003:01:00.0-phy           1                                 0mA     0mV     0mV

Thank you.

-Siddhartha V

ToradexAI · March 6, 2026, 4:52am

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

Let me provide some guidance based on the available information about the Verdin i.MX95 EVK.

Important Context About i.MX95 EVK Support

First, it’s important to understand that the i.MX95 Verdin EVK has a unique support structure. The EVK is made from a Toradex + NXP partnership with shared ownership (1). This means that some typical Toradex offerings might not be available or fully-supported on the EVK compared to standard Toradex SoMs (1).

According to the support scope documentation, the EVK has:

BSP: From NXP (1)
TorizonOS: Community Support - Limited (1)
Documentation: Limited/Private (NXP + Toradex) (1)

CAN Interface Configuration

Based on your observations, it appears the CAN transceivers are indeed controlled through GPIO expanders, but the specific pin mappings and configuration details for the PCAL6524 connections to the CAN transceiver EN and STB signals are not readily available in the public documentation.

Your regulator summary output shows that the CAN regulators are present but may not be properly configured:

can1-en and can2-en are enabled
can1-stby is disabled while can2-stby is enabled
The I2C communication with the GPIO expander at address 0x34 is failing

Recommendations

Given the limited public documentation for the EVK and the partnership nature of this product, I recommend:

Contact Toradex Support Directly: Since this is an EVK with limited public documentation (1), the specific PCAL6524 pin mappings and required device tree configurations may only be available through direct support channels.
Check NXP Resources: Since the BSP comes from NXP (1), you may also need to consult NXP’s documentation and support for the specific GPIO expander configuration.
For Future Projects: Consider migrating to a standard Toradex i.MX95-based SoM when available, which will have full Toradex support, complete documentation, and standard Toradex tooling support (1).

The CAN interface setup documentation (2) mentions that most Toradex SoMs have CAN buses enabled by default and don’t need additional configuration, but the EVK appears to be a special case requiring specific GPIO expander setup.

Best regards, Toradex AI Assistant.

Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

siddharthav · March 6, 2026, 4:56am

No the issue is not addressed yet.

Could anybody in in community guide with some idea. will help a lot.

Best regards,

Siddharha V

ToradexAI · March 6, 2026, 4:56am

Hi Siddhartha,

Thank you for the follow-up. You’re right that the I²C communication failure with the GPIO expander is a key issue that needs to be resolved.

Troubleshooting the I²C GPIO Expander Issue

Based on your dmesg output, the adp5585 driver is failing to communicate with the device at I²C address 0x34 on both buses 1 and 2. This suggests either:

Wrong driver binding - The device tree may be configured to use the adp5585 driver instead of the correct pcal6524 driver
I²C bus/address mismatch - The device may be on a different I²C bus or address than expected
Hardware/power issue - The GPIO expander may not be powered or accessible

Diagnostic Steps

1. Verify I²C Bus and Address

Try scanning all available I²C buses to locate the PCAL6524:

# Check which I²C buses are available
ls /dev/i2c-*

# Scan each bus for devices
for i in /dev/i2c-*; do
    bus=${i##*/i2c-}
    echo "Scanning bus $bus:"
    i2cdetect -y $bus
done

2. Check Device Tree Configuration

The issue might be in the device tree binding. Look for:

Incorrect compatible property (should be something like "nxp,pcal6524" not "adp5585")
Wrong I²C bus assignment
Missing or incorrect GPIO expander configuration

3. Verify Power and Reset Sequences

Check if the GPIO expander requires specific power sequencing or reset signals that aren’t being properly handled.

Device Tree Structure Reference

Based on the Device Tree documentation (1), you should verify that your device tree follows the proper structure with correct compatible properties, reg addresses, and proper parent-child relationships for the I²C bus and GPIO expander nodes.

Limited EVK Support Context

As mentioned in my previous response, the i.MX95 Verdin EVK has limited documentation and community support (2). The specific PCAL6524 pin mappings and CAN transceiver control logic may require access to NXP’s private documentation or direct support from Toradex.

Recommendations for Next Steps

Check the actual device tree source being used to see how the GPIO expander is configured
Contact Toradex support directly with your specific EVK board revision and BSP version for the correct device tree configuration
Verify with NXP documentation since the BSP comes from NXP (2)

The root cause appears to be the I²C communication failure rather than CAN-specific configuration, so resolving the GPIO expander communication should be the first priority.

Best regards, Toradex AI Assistant.

Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

siddharthav · March 6, 2026, 6:18am

Thank you for the guidance. I have performed the requested scans across all I2C buses. Here are the findings which confirm a hardware/power dependency issue:

1. I2C Bus Scan Results
Bus 2 (the expected location for ADP5585) is completely unresponsive. No devices were detected.

Bus 1: Shows activity at 0x3d (HDMI), but 0x34 (ADP5585) is missing.

Bus 2: Empty.

Bus 6: Shows the PCAL6524 at 0x23 (UU)—this confirms the GPIO expander is alive, but the transceivers it controls remain unpowered.

2. GPIO/Regulator State
Even though the PCAL6524 is functional, the CAN control lines are stuck in a disabled state because of the regulator dependency on the missing ADP5585:
Plaintext

gpiochip4: GPIOs 640-663, parent: i2c/6-0023, 6-0023:
gpio-640 (regulator-can1-stby ) out lo
gpio-642 (regulator-can1-en ) out lo
gpio-643 (regulator-can2-stby ) out lo
gpio-645 (regulator-can2-en ) out lo

The kernel is reporting “deferred probe” for the CAN transceiver supply because 2-0034 is not ready.

3. Question for the Team
Since Bus 2 is dead and the ADP5585 is unreachable, is there a recommended way to bypass this power dependency in the Device Tree to force the PCAL6524 to drive these lines HIGH? Or is there a physical jumper/power requirement on the Verdin V1.3 baseboard specifically for I2C Bus 2?

Bro can you reply like this for Ai :

Thank you for the guidance. I have performed the requested scans across all I2C buses. Here are the findings which confirm a hardware/power dependency issue:

1. I2C Bus Scan Results

Bus 2 (the expected location for ADP5585) is completely unresponsive. No devices were detected.

Bus 1: Shows activity at 0x3d (HDMI), but 0x34 (ADP5585) is missing.



Bus 2: Empty.



Bus 6: Shows the PCAL6524 at 0x23 (UU)—this confirms the GPIO expander is alive, but the transceivers it controls remain unpowered.

2. GPIO/Regulator State

Even though the PCAL6524 is functional, the CAN control lines are stuck in a disabled state because of the regulator dependency on the missing ADP5585:

Plaintext

gpiochip4: GPIOs 640-663, parent: i2c/6-0023, 6-0023:

gpio-640 (regulator-can1-stby ) out lo

gpio-642 (regulator-can1-en ) out lo

gpio-643 (regulator-can2-stby ) out lo

gpio-645 (regulator-can2-en ) out lo

The kernel is reporting “deferred probe” for the CAN transceiver supply because 2-0034 is not ready.

3. Question for the Team

Since Bus 2 is dead and the ADP5585 is unreachable, is there a recommended way to bypass this power dependency in the Device Tree to force the PCAL6524 to drive these lines HIGH? Or is there a physical jumper/power requirement on the Verdin V1.3 baseboard specifically for I2C Bus 2?

logs :

root@imx95-19x19-verdin:~# for i in /dev/i2c-*; do
> bus=${i##*/i2c-}
> echo "Scanning bus $bus:"
> i2cdetect -y $bus
> done
Scanning bus 1:
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- UU -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Scanning bus 2:

0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Scanning bus 3:

0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- UU -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Scanning bus 4:

0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- 0b -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- 25 -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Scanning bus 5:

0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Scanning bus 6:

0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- UU -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- 41 -- -- -- 45 -- -- 48 49 4a 4b -- -- -- --
50: 50 -- UU -- -- -- -- 57 -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- 6a -- -- -- -- --
70: -- -- -- -- -- -- -- --

root@imx95-19x19-verdin:~# dmesg | grep -E "i2c|adp5585|pcal6524"

[ 0.512572] platform 4acf0000.dsi: Fixed dependency cycle(s) with /soc/bus@44000000/i2c@44350000/hdmi@3d
[ 0.539805] platform 4ad30000.csi: Fixed dependency cycle(s) with /soc/bus@42000000/i2c@42530000/ap1302_mipi@3c
[ 0.569395] platform 4c1f0040.phy: Fixed dependency cycle(s) with /soc/bus@42000000/i2c@426d0000/tcpc@52/connector
[ 1.380512] i2c_dev: i2c /dev entries driver
[ 1.902056] platform 4ad30000.csi: Fixed dependency cycle(s) with /soc/bus@42000000/i2c@42530000/ap1302_mipi@3c
[ 1.912028] i2c 2-003c: Fixed dependency cycle(s) with /soc/csi@4ad30000
[ 1.919262] adp5585 2-0034: error -EIO: Failed to read device ID
[ 1.925091] adp5585 2-0034: probe with driver adp5585 failed with error -5
[ 1.955699] i2c i2c-2: LPI2C adapter registered
[ 1.961446] i2c i2c-3: LPI2C adapter registered
[ 1.982672] i2c i2c-4: LPI2C adapter registered
[ 1.988041] i2c i2c-5: LPI2C adapter registered
[ 1.994001] i2c 6-0052: Fixed dependency cycle(s) with /soc/usb@4c010010/usb@4c100000
[ 2.001778] i2c i2c-6: LPI2C adapter registered
[ 2.007285] platform 4acf0000.dsi: Fixed dependency cycle(s) with /soc/bus@44000000/i2c@44350000/hdmi@3d
[ 2.016595] platform hdmi-connector: Fixed dependency cycle(s) with /soc/bus@44000000/i2c@44350000/hdmi@3d
[ 2.026229] i2c 1-003d: Fixed dependency cycle(s) with /soc/dsi@4acf0000
[ 2.032834] i2c 1-003d: Fixed dependency cycle(s) with /hdmi-connector
[ 2.039948] adp5585 1-0034: error -EIO: Failed to read device ID
[ 2.045755] adp5585 1-0034: probe with driver adp5585 failed with error -5
[ 2.052627] i2c i2c-1: LPI2C adapter registered
[ 2.899521] i2c 6-0052: Fixed dependency cycle(s) with /soc/usb@4c010010/usb@4c100000
[ 2.907474] platform 4c100000.usb: Fixed dependency cycle(s) with /soc/bus@42000000/i2c@426d0000/tcpc@52
[ 3.003576] virtio_rpmsg_bus virtio0: creating channel rpmsg-i2c-channel addr 0x1
[ 3.022514] i2c-rpmsg virtio0.rpmsg-i2c-channel.-1.1: new channel: 0x400 -> 0x1!
[ 19.705191] i2c 2-003c: deferred probe pending: i2c: supplier regulator-dvdd not ready

root@imx95-19x19-verdin:~# cat /sys/kernel/debug/gpio | grep -E "can|stby|en"

gpiochip0: GPIOs 512-543, parent: platform/43810000.gpio, 43810000.gpio:
gpiochip1: GPIOs 544-575, parent: platform/43820000.gpio, 43820000.gpio:
gpiochip2: GPIOs 576-607, parent: platform/43840000.gpio, 43840000.gpio:
gpio-604 ( |regulator-mac-en ) out lo ACTIVE LOW
gpiochip3: GPIOs 608-639, parent: platform/43850000.gpio, 43850000.gpio:
gpiochip4: GPIOs 640-663, parent: i2c/6-0023, 6-0023, can sleep:
gpio-640 ( |regulator-can1-stby ) out lo
gpio-642 ( |regulator-can1-en ) out lo
gpio-643 ( |regulator-can2-stby ) out lo
gpio-645 ( |regulator-can2-en ) out lo
gpio-648 ( |regulator-aqr-stby ) out hi
gpio-661 ( |regulator-aqr-en ) out hi

Best regards,

Siddhartha V