- Forums
- Product Forums
- General Purpose MicrocontrollersGeneral Purpose Microcontrollers
- i.MX Forumsi.MX Forums
- QorIQ Processing PlatformsQorIQ Processing Platforms
- Identification and SecurityIdentification and Security
- Power ManagementPower Management
- Wireless ConnectivityWireless Connectivity
- RFID / NFCRFID / NFC
- Advanced AnalogAdvanced Analog
- Neural Processing UnitsNeural Processing Units
- MCX Microcontrollers
- S32G
- S32K
- S32V
- MPC5xxx
- Other NXP Products
- S12 / MagniV Microcontrollers
- Powertrain and Electrification Analog Drivers
- Sensors
- Vybrid Processors
- Digital Signal Controllers
- 8-bit Microcontrollers
- ColdFire/68K Microcontrollers and Processors
- PowerQUICC Processors
- OSBDM and TBDML
- S32M
- S32Z/E
-
- Solution Forums
- Software Forums
- MCUXpresso Software and ToolsMCUXpresso Software and Tools
- CodeWarriorCodeWarrior
- MQX Software SolutionsMQX Software Solutions
- Model-Based Design Toolbox (MBDT)Model-Based Design Toolbox (MBDT)
- FreeMASTER
- eIQ Machine Learning Software
- Embedded Software and Tools Clinic
- S32 SDK
- S32 Design Studio
- GUI Guider
- Zephyr Project
- Voice Technology
- Application Software Packs
- Secure Provisioning SDK (SPSDK)
- Processor Expert Software
- Generative AI & LLMs
-
- Topics
- Mobile Robotics - Drones and RoversMobile Robotics - Drones and Rovers
- NXP Training ContentNXP Training Content
- University ProgramsUniversity Programs
- Rapid IoT
- NXP Designs
- SafeAssure-Community
- OSS Security & Maintenance
- Using Our Community
-
- Cloud Lab Forums
-
- Knowledge Bases
- ARM Microcontrollers
- i.MX Processors
- Identification and Security
- Model-Based Design Toolbox (MBDT)
- QorIQ Processing Platforms
- S32 Automotive Processing Platform
- Wireless Connectivity
- CodeWarrior
- MCUXpresso Suite of Software and Tools
- MQX Software Solutions
- RFID / NFC
- Advanced Analog
- Neural Processing Units
-
- NXP Tech Blogs
- Home
- :
- Translated Content
- :
- Multi Source Translation Content
- :
- 2414329_en-US
2414329_en-US
2414329_en-US
2414329_en-US
Hi NXP Team,
The installed UUU executable reports:
libuuu_1.5.21-0-g1f42172
We use:
sudo uuu -b emmc_all ~/Downloads/flash.bin *.wic
The built-in emmc_all script writes the complete .wic image using:
FB: flash -raw2sparse all _image
It then writes the bootloader, configures eMMC boot selection, and finishes with FB: done.
The script contains no explicit persistent flash-in-progress completion metadata handling or readback hash verification step.
If flashing is interrupted during the .wic write, the cluster can subsequently boot and display the updated HMI. We suspect that an existing usable bootloader and sufficient written boot,rootfs content permit this, but the selected slot and completeness of its contents are not yet confirmed.
Please advise how to add a power-loss-tolerant completion check that blocks normal boot from both slots after interrupted factory flashing, while preserving USB recovery. The metadata must remain valid independently of the full .wic write and bootloader update.
Hello,
An official solution is not implemented but you can customize the uuu script, the built-in emmc_all flow is simply a UUU script based on Fastboot and U-Boot commands, and it can be modified or replaced by a custom uuu.auto file. U-Boot commands can also be executed through FB: ucmd. This means you should add custom steps such as setting a "flash in progress" flag before programming and clearing it only after verification succeeds.
U-Boot Boot Count / Boot Limit
The U-Boot tree includes support for:
CONFIG_BOOTCOUNT_LIMIT
bootcount
bootlimit
altbootcmd
CONFIG_BOOTCOUNT_FS
When bootcount exceeds bootlimit, U-Boot executes altbootcmd instead of the normal bootcmd. This mechanism can be used to redirect the system to a recovery mode such as Fastboot