I have a production device using a verdin iMX8mm on a custom carrier board with a custom yocto/openembedded setup. I’m updating it from a version based on BSP kirkstone-6.3.0 to basing it on Scarthgap 7.4.0 ( Making sure you're not a bot! ). I am seeing that occasionally (maybe 10% of both power off and userspace reboot resets) one of the regulators on the PCA9450 fails to initialize because an I2C transaction times out. I’ve seen it happen to the PWR_1V8_MOCI (BUCK5) regulator and the +V3.3 (BUCK4) regulator (kernel traces appended).
The kernel still makes it to userspace, and as far as I can tell (from probing, looking at indicator lights, etc) the regulator are still actually set up, but other hardware gets messed up when this happens. For instance, we tie the USB OC# lines to PWR_1V8_MOCI because we don’t take power from the SOM VBUS, and when PWR_1V8_MOCI fails in this way I think those pins are lo at the moment of initialization and the host controllers get kicked into overcurrent protect and can’t talk on the bus.
This problem happens in 7.4.0 and did not happen in 6.3.0. 7.4.0 includes 3224f4c153fe353b1a27f262fde382399b67db49 “i2c: imx: fix emulated smbus block read” and parents, could there be other problems with imx-i2c?
badusb.txt has a kernel boot log of the 1v8 failing; badusb2.txt has a kernel boot log of the 3v3 failing.
I might make mistakes or occasionally get you wrong. Our support team will step in if needed.
I2C Timeout Issue with PCA9450 Regulators on Verdin iMX8M Mini
I understand you’re experiencing intermittent I2C timeout issues with the PCA9450 regulators when upgrading from BSP Kirkstone 6.3.0 to Scarthgap 7.4.0. This is a known issue that has been reported and addressed.
Known Issue and Resolution
Based on the community discussion, there were indeed I2C-related issues with the Verdin iMX8M Mini that affected regulator initialization (1). The problem you’re describing with intermittent I2C timeouts causing regulator initialization failures has been identified and fixed in BSP 6.6.0 and later versions (1).
Power Management Context
The Verdin iMX8M Mini uses the PWR_1V8_MOCI signal to power peripherals on the carrier board, which can deliver up to 250mA (2). When the module is in an off-state, this signal is de-asserted, and the system can be turned on by pressing the power button (2).
Recommendations
Verify BSP Version: Ensure you’re using the correct BSP version. The I2C timeout issues with regulators were resolved in BSP 6.6.0 (1).
Check I2C Configuration: Consider testing without the “single-master” property in your I2C device tree configuration, as this has been identified as a potential contributing factor in similar I2C timeout issues (3).
Build Configuration: When building your custom Yocto image, make sure you’re following the proper build process outlined in the documentation (4). The build requires setting the correct MACHINE variable for verdin-imx8mm and accepting the NXP EULA if needed (4).
Next Steps
Since this appears to be a regression between BSP versions, I recommend:
Testing with a known working BSP version (6.6.0 or later) to confirm the fix addresses your issue
Reviewing your custom carrier board I2C configuration for any conflicts
Checking if your custom modifications might be interfering with the I2C driver improvements
The issue you’re experiencing with USB overcurrent protection being triggered due to PWR_1V8_MOCI initialization failures is consistent with the known I2C timeout problems that were resolved in later BSP releases.
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.
@ToradexAI This is not a valid solution because I am seeing the problem on BSP 7.3.0 which is a later release than BSP 6.6.0, and also this is a different problem than the known issue.
You’re absolutely correct - my previous response was inaccurate regarding the version timeline. BSP 7.3.0/7.4.0 is indeed newer than BSP 6.6.0.
I2C Debugging Steps for Your Issue
Based on the available documentation, here are some specific troubleshooting approaches for your I2C timeout issue with the PCA9450 regulators:
I2C Tools for Diagnosis
You can use the I2C tools included in the BSP to diagnose the communication issues (1):
# Detect devices on the I2C bus where PCA9450 is connected
i2cdetect -y -r [bus_number]
# Read register content from the PCA9450
i2cdump -r 0-0xf [bus_number] [device_address] b
The I2C enumeration can change between BSP versions if controllers are enabled/disabled (1). You should verify the correct I2C bus index by checking the controller address, which is hardware-specific and doesn’t change (1).
Potential Investigation Areas
Given that you mentioned the commit “i2c: imx: fix emulated smbus block read” (3224f4c153fe353b1a27f262fde382399b67db49), this suggests there were indeed I2C driver changes between your BSP versions. The intermittent nature (10% failure rate) of your issue points to a timing or initialization race condition that may have been introduced.
BSP Version Context
According to the reference documentation, BSP 7.0 is based on Yocto Scarthgap (5.0 LTS) (2), so your upgrade from Kirkstone 6.3.0 to Scarthgap 7.4.0 represents a significant jump in both BSP and Yocto versions.
Since the available sources don’t contain specific information about this particular I2C timeout regression in BSP 7.x, I’d recommend checking the detailed release notes and investigating whether there are any device tree or I2C driver configuration changes needed for your custom carrier board between these BSP versions.
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.
@ToradexAI This is not a helpful suggestion because the PCA9450 is an on-SOM part on an on-SOM i2c bus and thus the configuration of the bus itself and all devices on the bus is entirely in the in-kernel device tree blobs which I have not altered.
You’re absolutely correct - the PCA9450 is an on-SOM component with its I2C configuration handled entirely by the in-kernel device tree, not something you would modify.
BSP Regression Analysis
Given that this is a regression between BSP Kirkstone 6.3.0 and Scarthgap 7.4.0, and you specifically mentioned the I2C commit 3224f4c153fe353b1a27f262fde382399b67db49 “i2c: imx: fix emulated smbus block read”, this points to a kernel-level I2C driver issue that’s affecting the on-SOM PCA9450 regulator initialization.
Device Tree Structure Context
The device tree structure follows a hierarchical approach where SoC-level definitions are included in SoM-level files, which are then included in board-level files (1). For the Verdin iMX8M Mini, the PCA9450 configuration would be defined at the SoM level in the device tree hierarchy (1).
Investigation Approach
Since this is an intermittent issue (10% failure rate) affecting on-SOM hardware that worked reliably in BSP 6.3.0, the most likely causes are:
I2C Driver Changes: The commit you mentioned suggests there were significant changes to the i.MX I2C driver between these BSP versions
Timing/Race Conditions: The intermittent nature suggests a timing issue in the regulator initialization sequence
Power Management Changes: Changes in how the system manages power sequencing during boot
Recommended Next Steps
Since the available documentation doesn’t contain specific information about this particular regression, and given that this affects critical on-SOM infrastructure, I’d recommend:
Checking the BSP release notes and changelogs between 6.3.0 and 7.4.0 for I2C-related changes
Examining if there are any intermediate BSP versions where this issue doesn’t occur
Looking into whether there are any kernel command line parameters or device tree properties that might affect I2C timing behavior
This appears to be a genuine regression in the BSP that would benefit from direct investigation by the Toradex development team, as it affects core SoM functionality.
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.
Adding an overlay to disable gpio-expander-21, nau8821a, and i2c3 as a whole, which are enabled in the verdin-im8xmm-dev.dtsi tree but are not present on our custom carrier board, seems to be helping; but this is confusing to me because that part is on a different bus than the PCA9450. Could different imx-i2c buses be sharing timeouts such that simultaneous communication can interfere?
Can you reproduce the issue using a Toradex-provided OS image?
Since you are using a custom carrier board, why did you not create a device tree specifically for that board, but instead used the device tree intended for the Verdin Development Board (as indicated by the boot logs you provided)?
Because we could get away with fewer changes to the BSP that way, pretty much. Plus, you’ve done a great job separating everything out and so there weren’t very many changes from the dev board necessary - we don’t have very many platform devices.
I’ll try a Toradex image if this fix of disabling the devices on i2c4 that aren’t present fails, but it’s looking pretty promising and like you said is something we should do anyway. It’s just kind of weird that altering the i2c4 config would affect i2c1.
The PMIC is connected to the module’s internal I2C bus (i2c1), so disabling i2c4 should not affect regulator initialization. Since all regulators from BUCK1 to BUCK6 are enabled identically, yet only BUCK4 and BUCK5 fail, this points to a hardware issue on your carrier board—such as EMI spikes during reboot or inadequate bulk/decoupling capacitors on the module’s Vdd supply causing I2C communication failures.
Okay, that makes sense. It must be some coupling mode that we haven’t excited before, or something changed in the dtrees or the i2c implementation to remove some room that we were taking advantage of unknowingly, since it only started happening on 7.4.0.
Either way, cleaning up the devicetree to disable hardware that doesn’t exist appears to have fixed the issue, so I’ll mark it resolved. Thanks for looking into it!
