HAR-8347 | Known Issue | Colibri iMX8X CSI FFC connector not accessible with the Iris Carrier Board because of X19 touch connector | Colibri iMX8X V1.0 | |
Customer Impact: Customers could not use the X3 CSI connector of the Colibri iMX8X mounted with Iris Carrier Board. Description: The Iris Carrier Board touch screen connector X19 makes usage of CSI cable from Colibri iMX8X module not possible due to mechanical interference. Workaround: There is no identified workaround. |
HAR-6903 | Known Issue | Triggering Recovery Mode on the Colibri iMX8X takes long or the SoM does not go into Recovery Mode | Colibri iMX8X V1.0D Colibri iMX8X V1.0A Colibri iMX8X V1.0B Colibri iMX8X V1.0C | |
Customer Impact: Triggering Recovery Mode on the SoM takes long or the SoM does not go into Recovery Mode. Description: In some cases, the recovery button of carrier boards needs to be pressed for 6-10s after powering up the SoM to get it into Recovery Mode. In other cases, the SoM does not go into recovery mode at all, even after the 6-10s period has elapsed. The issue is caused by the combination of the NXP i.MX8X SoC's boot ROM code and the behavior of the USB interface of the host computer the USB OTG port of the carrier board is connected to. On the SoC side, at power-up, a boot monitor timer is initialized. During USB enumeration in serial download mode, the host side may enumerate multiple times until enumeration succeeds. The enumeration retries take time and result in a delayed entry into Recovery Mode. In some other cases, the maximum number of enumeration retries may get exceeded, which results in an enumeration failure. Under corner conditions, the ROM code may not be able to refresh the boot monitor timer due to the behavior of the USB host, causing a device system reset. Workaround: In general, changing to a different host is the most effective way to avoid the issues. NXP may potentially fix this issue in the future. |
HAR-4980 | Known Issue | Instability Issue (flickering) on the i.MX8 QXP and i.MX8 DX LVDS Interface | Colibri iMX8X V1.0 | Colibri iMX8X V1.0D |
Customer Impact: The contents appearing on displays utilizing the LVDS or the MIPI DSI interface of the SoM may be blurry or using incorrect colors. Potentially the screen may be observed to go black, which the driver can perceive as the screen not working. The errata does not affect customers not utilizing these interfaces. Description: On 20.07.2020, Toradex has been informed about an LVDS/MIPI DSI instability issue (flickering) affecting NXP's i.MX 8QuadXPlus and i.MX 8DualX SoCs. The affected SoCs have been used in various sample versions of our Colibri iMX8X SoMs, up to V1.0C.
For the affected parts, the LVDS/MIPI DSI display interface clock may not run stable (depending on the die temperature and the voltage applied).
NXP stated that “This failure causes information to be displayed blurry or with the wrong color on the screen. Potentially the screen may be observed to go black, which the driver can perceive as the screen not working.” Workaround: Reducing the die temperature of the SoC can help reduce the probability of seeing the issue. This could be achieved by either reducing the ambient temperature and the computational load of the SoC, or improving the thermal solution applied. We are working with NXP to get screened SoC parts that are not affected by this issue. This issue will be fixed in the next product version. |
HAR-4396 | Known Issue | Dropping Support of HiFi 4 DSP Feature | Colibri iMX8X V1.0 | Colibri iMX8X V1.0D |
Customer Impact: The HiFi 4 feature is not going to be available and supported in future hardware versions of the SoM, therefore customer applications potentially leveraging the feature are not going to be compatible with those future SoM hardware versions. Description: The HiFi 4 DSP feature is no longer going to be featured and supported in future hardware versions of this product. Even though some current product versions may theoretically feature the IP in question, to avoid having compatibility issues in the future, please don't use the feature. Workaround: There is no available workaround. |
HAR-4304 | Known Issue | Inaccurate ADC reading on Colibri iMX8X Module | Colibri iMX8X V1.0 | Colibri iMX8X V1.0D |
Customer Impact: On the affected product, ADC conversion results are inaccurate. Description: The ADC input sampling time can be set between 3 and 131 clocks (of the 24MHz used).
According to the ADC datasheet, at the longest sampling time of 131 clocks, the source output resistance must not be higher than 5kOhm. The resistor value assembled on the affected product version was 10kOhm.
This leads to the sampling capacitor not being fully charged to the input voltage and thus inaccurate ADC conversion results.
In the fixed product versions, the series resistors value has been changed to 1kOhm. Workaround: There is no available workaround. |
HAR-1034 | Known Issue | External RGMII interface would require 1.8V IO voltage | Colibri iMX8X V1.0 | |
Customer Impact: If the second Ethernet port is used in the RGMII mode, the I/O voltage of 3.3V is not compliant with the specifications of NXP. Using the module pins as RMII or any other alternate function is not affected. Description: According to the NXP datasheet for the i.MX 8X SoC, the I/O voltage of the RGMII interface is limited to 1.8V and 2.5V. The RGMII signals of the second Ethernet port is available as alternate functions of the RGB LCD interface. On the Colibri iMX8X, the I/O voltage of these signals is fixed to 3.3V. The maximum voltage of the pins itself is not violated. If the edge connector pins are used for any other function (e.g. RGB LCD or GPIO), the I/O voltage is fully compliant. Even using the pins as RMII for 100Mb/s Ethernet is fully compliant. Only when using the interface pins as RGMII, the I/O voltage is not compliant with the NXP specifications.
No physical damage is expected when using the signals as RGMII with 3.3V I/O voltage since the actual SoC pins are rated for an absolute maximum voltage of 3.6V. However, the timing might not be compliant with the RGMII specifications. Workaround: Use the second Ethernet port as RMII instead of RGMII. However, this limits the maximum interface speed to 100Mb/s (Fast Ethernet). RGMII would allow transfer rates up to 1Gb/s (Gigabit Ethernet). |