 HAR-11313 | Known Issue | Main crystal frequency inaccuracy | Colibri iMX7D 1GB V1.1A | |
Description: The main crystal frequency (24MHz) is with 166ppm inaccuracy. Since the i.MX 7 has a dedicated MEMS oscillator for the Ethernet, the Ethernet frequency is not affected. Other interfaces such as USB will potentially suffer from the wrong main clock, but the inaccuracy is within tolerance.
• For USB High-Speed, the clock source inaccuracy shall be less than +/- 500ppm.
• For UART, there is no standard, but 5000ppm is a good common ground.
• Other interfaces in Colibri iMX7 provide their own clock and they are unaffected.
166ppm is not out of tolerance for the interfaces available on Colibri iMX7 apart from the Ethernet (+/- 100ppm), but for that, the Colibri iMX7 has a dedicated oscillator. Workaround: A customer wanting to use an external PHY would need an extra clock (although ext. PHY interface is not part of the Colibri standard), make sure to update the software. |
| HAR-11310 | Known Issue | Recovery Pin Voltage is at 1.6V During Power Up | Colibri iMX7S
Colibri iMX7D | |
Description: If the module edge pin 91 (recovery mode) is left unconnected, the voltage during the power up sequence is only at around 1.6V. There is a 100kΩ pull up resistor on the module. However, there is also the SoC pin EPDC_D8 connected to this SODIMM pin 91. This SoC pin features by default an 100kΩ pull down resistor which causes a voltage level of 1.6V.
The 1.6V are not an issue since the threshold for going into recovery mode is at 1V. However, if there is any further load on this pin during the ramping up of the power rails, the module could enter the recovery mode unintentionally. This prevents the module from booting regularly. Workaround: Either make sure there is no further load pulling down the SODIMM pin 91 during the power up sequence or add an additional stronger pull up resistor to this pin.
If the pin 91 is not used, it is recommended to disable the internal pull up resistor after the module is booted. This makes sure the pin has a defined level. |
| HAR-11307 | Known Issue | Repeated Reset Pulses Shuts Down the Module | Colibri iMX7S 256MB V1.1C WinEC
Colibri iMX7D 512MB V1.1D WinEC
Colibri iMX7D 512MB V1.1A | |
Description: If there are multiple pulses within less than 5 seconds on the nRESET_EXT input signal (e.g. by pressing the reset button multiple times), the power of the module is shut down. The shutdown can happen with a delay of a couple of seconds.
There is a circuit on the module which generates a power button signal on every falling edge of the nRESET_EXT input. This power button signal is used by the i.MX 7 power management unit for starting the power up cycle after the module was powered off. By pressing the reset button multiple times, the power button signal can get accumulated. If the power button signal gets longer than 5 seconds, the power management unit performs an immediately power off.
This only happens if there are multiple (normally more than three) nRESET_EXT pulses within 5 seconds. Holding down the reset button for a longer period does not cause any issue. Workaround: Make sure there are not repeated pulses on the nRESET_EXT input. Ideally, the nRESET_EXT signal should be high for at least 2 seconds until the next reset impulse is generated. |
| HAR-11304 | Known Issue | Some Modules Cannot Wake up from PMIC Shutdown Mode | Colibri iMX7S 256MB V1.1A WinEC
Colibri iMX7S 256MB V1.1B WinEC
Colibri iMX7D 512MB V1.1A WinEC
Colibri iMX7D 512MB V1.1C WinEC
Colibri iMX7D 512MB V1.0A WinEC
Colibri iMX7D 512MB V1.1B WinEC
Colibri iMX7S 256MB V1.0A WinEC | Colibri iMX7S 256MB V1.1C WinEC
Colibri iMX7D 512MB V1.1D WinEC |
Description: If a module shut down is proceeded by the software which turns off the power management IC (PMIC), certain module can only be restarted again if all power rails are removed (including VCC_BATT) and reapplied. This means, as long as the RTC is running (VCC_BATT available), the module cannot be started.
All other sleep modes of the modules are not affected by this issue.
There is a circuit on the module which should wake up the module if the reset button is pressed or the main power rail (3V3) is reapplied to the module. This circuit creates a power button impulse for the i.MX 7 SoC power management unit. Due to manufacturing tolerances and temperature dependencies, this impulse can be shorter than the minimum required duration. In this case, the i.MX 7 ignores the impulse and does not wake up the power management unit. Workaround: Do not shut down the PMIC. Leave the PMIC running after finishing the software shut down request. The module main input rail can be removed without issue as long as no PMIC shut down request was executed. |
| HAR-11301 | Known Issue | Possible Noise on Audio Output during Reset Cycle | Colibri iMX7S
Colibri iMX7D | |
Description: The audio codec on the SGTL5000 on the module does not feature a dedicated reset input. If a sound is playing back during a reset cycle, the SGTL5000 remains in playback mode. The audio codec is then repeating the last short sample which is remains in its buffer. This creates an audible noise at the output. The actual noise depends on the sample which is in the buffer. This noise is retained until the audio codec is reinitialized during the booting process.
The issue only appears if the reset is initiated by the nRESET_EXT signal (e.g. pressing reset button on evaluation board). The effect has not been seed during software initiated reset cycles or regular power cycles. Workaround: There is currently no workaround available. Try to avoid pressing the reset button while any sound is played back from the on module audio codec. |
| HAR-11298 | Known Issue | Secure Boot Vulnerabilities (NXP ERR010872 and ERR010873) | Colibri iMX7S 256MB V1.1C WinEC
Colibri iMX7D 512MB V1.1D WinEC
Colibri iMX7D 512MB V1.1A
Colibri iMX7D 1GB V1.1A | |
Description: These errata are actually NXP errata affecting all i.MX and Vybrid processors. There are two issues in the boot rom when using the processors in a security enabled configuration (SEC_CONFIG[1] eFUSE is programmed). By default, this fuse is not programmed on Toradex modules. Customers not fusing this setting are therefore not affected by these issues.
Customers using the security enabled configuration are affected by these issues. More information can be found in the respective NXP errata documents:
https://docs.toradex.com/104705-err010872-secure-boot-vulnerability-erratum-preliminary-rev0.pdf
https://docs.toradex.com/104706-err010873-secure-boot-vulnerability-erratum-preliminary-rev0.pdf Workaround: Please refer to the above-mentioned documents for workarounds. |
| HAR-11295 | Known Issue | Some Modules do not Boot at certain Temperatures | Colibri iMX7S 256MB V1.1A WinEC
Colibri iMX7D 512MB V1.1A WinEC
Colibri iMX7D 512MB V1.0A WinEC
Colibri iMX7D 512MB V1.1B WinEC
Colibri iMX7S 256MB V1.0A WinEC | Colibri iMX7S 256MB V1.1B WinEC
Colibri iMX7D 512MB V1.1C WinEC |
Description: Some modules are not able to boot if the main power is applied. The issue only appears on a certain temperature range. Above and below this range, the module boots without issues. The temperature range depends on the module. Most of the affected modules have the non-working temperature range at higher temperatures.
If the issue appears, there is no console output on the UART_A. The boot ROM crashes in a very early stage. It is possible to enter into recovery mode and connect it to a host PC. But during downloading the code, the module is crashing.
The issue only appears if the module is tried to start directly from power up. If an additional reset cycle is initiated by pressing the reset button (additional nRESET_EXT cycle), it never occurs. The module works without any issue.
The issue has been seen only on modules with samples qualified i.MX 7 SoC. It has never seen with mass production qualified SoCs. The product version that is printed on the SoC starts with PCIMX7… on the sample qualified versions. The mass production qualified SoC have been assembled from the module versions Colibri iMX7D V1.1C and iMX7S V1.1B on. The printing on the SoC cases start with MCIMX7…
According to NXP, the issue could be related to silicon erratum #9516. This issue is resolved in the silicon revision 1.2 (mass production classified SoC). Workaround: The only workaround for the modules with sample qualified SoC is doing an additional reset cycle by pressing the reset button on the carrier board or cycling the nRESET_EXT (pin 26) signal. |
| HAR-9335 | Known Issue | SkyHigh eMMC's not properly initialized when booted from other media in pSLC mode Colibri iMX7 | Colibri iMX7D 1GB V1.1B | Colibri iMX7D 1GB V1.1B |
Customer Impact: When configuring and using the SkyHigh eMMC in MLC mode customers are not affected. Customers using pSLC (pseudo-SLC) mode and trying to boot from SD card the module may not work. Description: When configuring and using the SkyHigh eMMC in pSLC (pseudo-SLC) mode and trying to boot from SD card the module may not work. Workaround: There are three possible workarounds:
1) Access the eMMC from U-Boot before launching the Kernel by using the following command: ls mmc 0.4:0 /boot
2) Update the eMMC firmware according to the instructions:
https://developer.toradex.com/linux-bsp/how-to/hardware-related/firmware-update-skyhigh-emmc
3) Modules produced after 09.12.2022 are not affected |
| HAR-9270 | Known Issue | Endurance degradation of Colibri iMX7 modules with the SkyHigh eMMC in pSLC mode | Colibri iMX7D 1GB V1.1B | Colibri iMX7D 1GB V1.1B |
Customer Impact: Using the SkyHigh eMMC based module in pSLC (pseudo-SLC) mode and writing more than 32TB to the eMMC, will lock up the device, not allowing any further writes to the eMMC. Description: When configuring and using the SkyHigh eMMC in pSLC (pseudo-SLC) mode and writing more than 32TB to the eMMC, the eMMC firmware will lock up the device, not allowing any further writes to the eMMC. The theoretical lifetime data write capacity for SkyHigh eMMCs in pSLC mode would be 60TB. By default, Toradex doesn't enable the pSLC mode and therefore doesn't run into this problem. Workaround: SkyHigh implemented an FW fix. Customers using pSLC mode and writing more than 32TB during the lifetime of the product can execute a single-step FW update: https://developer.toradex.com/linux-bsp/how-to/hardware-related/firmware-update-skyhigh-emmc
Products produced after 09.12.2022 are not affected |
