HAR-10131 | Known Issue | Change OSC4 to a crystal based oscillator | 0037 Apalis iMX8 0067 Apalis iMX8 0047 Apalis iMX8 0048 Apalis iMX8 0049 Apalis iMX8 | Not applicable |
Customer Impact: The high level of Jitter typical of MEMS-based oscillators might cause, in certain situations, a negative result on the related Ethernet compliance section. We are not aware of any real-world impact on connectivity caused by this product limitation. Description: The oscillator used as a clock source for the Ethernet PHY has a frequency stability that is in line with the requirements of this IC. On the other hand, since it is a MEMS-based oscillator, it is affected by a high level of Jitter that might negatively impact the related test in the Ethernet compliance validation.
Succeding product revisions will feature a crystal-based oscillator, which ensures a lower level of Jitter. |
HAR-10048 | Known Issue | Operating temperature range limitation | 0037 Apalis iMX8 0067 Apalis iMX8 | |
Customer Impact: When powering up/booting the SoM at ambient temperatures of -30C and below, the Wi-Fi/Bluetooth module may fail to start and function properly. Description: Some Apalis iMX8 product configurations feature a Wi-Fi/Bluetooth module. The module featured on the System-on-Module (SoM) is limiting the effective operating temperature range of the product to -30C...85C. When powering up/booting the SoM at ambient temperatures of -30C and below, the Wi-Fi/Bluetooth module may fail to start and function properly. As the Wi-Fi/Bluetooth functionality is not considered boot-critical, the SoM may still be used throughout the full specified temperature range (-40C...85C). When powering up/booting the SoM at ambient temperatures of -30C and below, the warming up the Wi-Fi/Bluetooth module (by the heat dissipated by the other components) may eventually result in the Wi-Fi/Bluetooth module starting and functioning properly. Workaround: Power up/boot the SoM at ambient temperatures of -30C or above. If this is not feasible, monitor the status of the Wi-Fi/Bluetooth module in software after powering up/booting the SoM, and reset the SoM in case the Wi-Fi/Bluetooth module failed to start/initialize properly. The reset could be initiated both in software and hardware. Repeat this procedure until you have a functional Wi-Fi/Bluetooth module. |
HAR-9336 | Known Issue | Potential system crashes at full system load | 0037 Apalis iMX8 V1.0x 0047 Apalis iMX8 V1.0x 0067 Apalis iMX8 V1.1x 0037 Apalis iMX8 V1.1x 0047 Apalis iMX8 V1.1x 0049 Apalis iMX8 V1.1x 0048 Apalis iMX8 V1.0x 0048 Apalis iMX8 V1.1x | |
Customer Impact: The System-on-Chip (SoC) may crash and cause a system crash when running under high loads on the A72 and/or GPU cores. The actual manifestation and impact of the crash is unpredictable, and varies from a single non-functional interface to a completely non-functional system. Description: The Apalis iMX8 is featuring the NXP i.MX8 System-on-Chip (SoC). There's an issue affecting the QuadMax and QuadPlus variants of the SoC. The System-on-Chip (SoC) may crash and cause a system crash when running under high loads on the 2xA72 and GPU cores. The actual manifestation and impact of the crash is unpredictable, and varies from a single non-functional interface to a completely non-functional system. Workaround: Customers having performance issues should reduce A72 max frequency from 1.6 GHz to 1.3 GHz and disable GPU’s Overdrive Mode - this reduces the clock from 800 MHz to 650 MHz. |
HAR-8522 | Known Issue | The Audio Codec Does Not Reset Correctly with Low-Impedance Headphones Plugged in | Apalis iMX8 V1.1B Apalis iMX8 V1.1C Apalis iMX8 V1.0A Apalis iMX8 V1.0B Apalis iMX8 V1.1A | |
Customer Impact: After a software-initiated reset cycle (software reboot), the SGTL5000 audio codec may not work anymore. Description: The headphone output signals of the SGTL5000 audio codec (SODIMM pin 316: AAP1_HP_L and SODIMM pin 318: AAP1_HP_R) have a DC offset of around 1.65V. Series capacitors must be placed between the SoM edge connector pins and the headphones to block this offset voltage. The Toradex reference design uses values between 47µF and 100µF for this purpose.
With headphones plugged in, these series capacitors get charged with 1.65V. In a software-initiated reset cycle (software reboot), all power rails of the SoM are turned off. After a delay of 5ms, the rails get re-enabled, and the SoM starts booting. The SGTL5000 can only be reset by power cycling it, as the codec does not have a dedicated reset input.
If headphones are plugged in during a software reboot, the voltage at the series capacitors is backfeeding to the power rails of the audio codec. The series capacitors are not fully discharged since the power rails are turned off only for around 5ms. The voltage at the 3.3V analog rail of the audio codec remains at about 1.5V. The residual voltage can cause the audio codec to not reset properly. This reset issue can prevent the audio codec from functioning properly. Power cycling the SoM resolves the problem.
The issue only occurs during software reboots. Regular power cycles are not affected. The issue mainly appears when low-impedance headphones are used. Occurrences are less frequent with high-impedance headphones (devices with smaller drivers).
When using the headphone output as a high-impedance line output signal, the resulting backfeeding current is low enough to not cause an issue. Without headphones plugged in, the circuit is open, and therefore no backfeeding occurs. This means, that there is no residual voltage, and consequently, the software reset works properly. Workaround: A locked-up audio codec can be recovered by power cycling the SoM.
Using high-impedance headphones instead of low-impedance ones reduces the backfeeding current (and therefore the risk of having this issue manifest itself). Using the headphone output as a line-out signal with an external amplifier further helps to reduce the backfeeding.
In case only high-impedance headphones are used (or the interface is used as a line-out signal), the series capacitors' values can be reduced without sacrificing the signal quality at low frequencies. Series capacitors with lower capacity discharge faster and reduce the residual voltage during a software reboot.
If the audio codec needs to be able to reliably reset when used in combination with low-impedance headphones, an additional discharge circuit can be added to the carrier board. The idea behind this circuit is to discharge the series capacitors while the RESET_MOCI# signal is low. A resistor value of 47R is a good choice for series capacitors with values between 47µF and 100µF. The example circuit can be found in the related errata document. |
HAR-8448 | Known Issue | Triggering Recovery Mode on the Apalis iMX8 takes long or the SoM does not go into Recovery Mode | Apalis iMX8 V1.1B Apalis iMX8 V1.1C Apalis iMX8 V1.0A Apalis iMX8 V1.0B Apalis iMX8 V1.1A | Not applicable |
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.MX8 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-6830 | Known Issue | Apalis iMX8 Unexpected Reset States of some GPIO Pins | Apalis iMX8 1.1A Apalis iMX8 V1.1B Apalis iMX8 V1.1C | |
Customer Impact: In case of some of the GPIO-capable pins, the reset states are different from the ones documented in the previous versions of the module datasheet. The USBO1_EN and the USBH_EN signals are high during the reset state. Therefore, the USB power rails can get unintentionally enabled. Depending on the carrier board, other affected pins may have an impact on the behavior of the carrier board. It is advised to carefully check the updated reset state documentation in the module datasheet. Description: The pin configuration registers of the i.MX8 SoC have reset states. These reset states have been stated in the Toradex Apalis iMX8 datasheet (document revision 1.1 and earlier) as reset states in section 4.4.
However, the i.MX 8 SoC features a System Controller Unit (SCU) that handles all of the pin configurations. The SCU comes with a firmware (SCFW) that has its own default pin configurations. By the time of the release of the RESET_MOCI# signal, the SCU already overrides the pin configurations. Therefore, the SCU default settings are the relevant reset states for the pins. In case of some of the GPIO-capable pins, the SCFW reset states are different from the register reset states. A comparison list can be found in this article: https://developer.toradex.com/knowledge-base/reset-state-of-the-imx8-soc-pins. The Apalis iMX8 datasheet (document revision 1.2 and newer) has been updated with the reset values dictated by the SCFW.
Despite the original intention, the USBO1_EN and the USBH_EN have pull-up resistors enabled instead of being pulled down during reset. This means that the USB power rails can get unintentionally enabled in the reset state of the module.
Depending on the carrier board, the different reset states of the SoC pins can result in unintended behavior. For example, on the Ixora carrier board V1.2A, the MMC1_D5 (pin 152) and MMC1_D6 (pin 156) are used for driving LEDs. By default, these two pins have pull-up resistors enabled instead of the pull-down. Therefore, the LEDs are lit during the reset cycle. Workaround: The values of the internal pull-up and pull-down resistors of the SoC are between 15kΩ and 50kΩ. These pull resistors can be disabled in the bootloader or during kernel boot. The issue caused by the unintentional pull-resistor states persists in time between the release of the reset signal and the bootloader configuring the IO pins in the intended state. In that case, an external pull-resistor on the carrier board can resolve the issue. According to measurements, adding a 10k pull-down resistor to a GPIO-capable pin with an internal pull-up resistor enabled results in a voltage level of around 0.6V. With an external 1k pull-down, the level goes below 100mV. However, these are just typical values at room temperature.
For the USBO1_EN and the USBH_EN signals, it is recommended to add a 10k pull-down resistor (or replacing the existing weak pull-down resistor). This keeps the power enable signal level below the maximum input low threshold of the USB power switch IC during the reset cycle. |
HAR-4399 | Known Issue | Instability Issue (flickering) on the i.MX 8QM and i.MX8QP LVDS Interface | Apalis iMX8 1.1A Apalis iMX8 V1.1B | Apalis iMX8 V1.1C |
Customer Impact: If the display interface (LVDS) is used, it may be unstable. This errata does not impact customers not utilizing this interface. Description: On 07.07.2020 we were informed about an LVDS instability issue (flickering) on new version of NXP i.MX8QM/iMX8QP which are used in our prototype Apalis iMX8 products until version 1.1.B.
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: We are working with NXP to get screened processors that do not manifest this issue. This issue will be fixed in the next product version. |
HAR-4398 | Known Issue | Dropping Support of HiFi 4 DSP Feature | Apalis iMX8 V1.1B | |
Description: The HiFi 4 DSP feature will be no longer supported on the future versions of this product. Please don't use this feature on any current product version which theoretically would support it. Workaround: None |
HAR-4305 | Known Issue | Inaccurate ADC reading on Apalis iMX8 Module | Apalis iMX8 1.1A Apalis iMX8 V1.1B | Apalis iMX8 V1.1C |
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: None. |
HAR-4106 | Known Issue | Power on after SW shut-down not possible | Apalis iMX8 1.1A | Apalis iMX8 V1.1B |
Description: If the RTC battery is present, it is not possible to turn on the module after shutting it down the PMIC in software. Workaround: Option 1: Do not use the software initiated PMIC shut down. It is possible to shut down the software for making sure the system is in a safe state for removing the power. But the command to the PMIC for shutting down should not be send. Leave the PMIC running and just remove the main input voltage from the module (remove VCC).
Option 2: Assemble C267 for making the power button signal pulse long enough. The capacitor C267 is not assembled on Apalis iMX8 modules with the version 1.1A or older. By assembling C267 with a 10µF 6.3V capacitor with the 0603 size. The power button signal pulse gets its required duration. This means the module can be turned on either by power cycling VCC or by pressing the RESET_MICO# button. |