- 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
- :
- 2400736_en-US
2400736_en-US
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
2400736_en-US
2400736_en-US
Hi @HQZ
Are you sure there is a valid image in the passive partition? What do you observe if you attach a debugger to the running target without resetting it after power-up? Did the device enter JTAG recovery mode? Or you can simply reset the device by your debugger and then check if it reached the entry point of your application.
If the device is stuck in an endless loop at address 0x2040012C, it indicates that it has entered JTAG recovery mode. This could also point to an issue with the IVT configuration or IVT integrity.
Also, is the image in the passive partition linked to run from the active partition address space, i.e. starting at 0x00400000?
Finally, are you using Secure Boot?
Regards,
Lukas
Hi @HQZ
“while Partition B firmware is linked starting at 0x600000” – this is the problem. Both images must be linked for active partition addresses – 0x400000. The applications are always running from active partition, not from passive partition.
Solution – use the same linker file for both projects.
It works with your debugger because debuggers set the program counter “manually” to entry point address which is found in elf file.
Regards,
Lukas
Hello@lukaszadrapa
Platform: S32K344, AB-Swap architecture. Independent firmware images are stored in Active Block and Passive Block separately. HSE Secure Boot is disabled. Problem Description: After calling HSE_ActivatePassiveBlock() to complete the Active/Passive partition switch, the device cannot automatically boot the target firmware after power cycle and reset. However, if the J-Link debugger is connected to the chip and "Start Application" is clicked within the debugger software, the swapped firmware runs normally. Additional background: Firmware resides in both Partition A and Partition B. The only difference between the two images is the LED blinking frequency. Partition A firmware is linked starting at 0x400000, while Partition B firmware is linked starting at 0x600000. After invoking HSE_ActivatePassiveBlock() and reset, I dumped flash contents with J-Link. The contents of Partition A and Partition B have been physically swapped, confirming that HSE_ActivatePassiveBlock() takes effect. Questions: 1. What is the root cause of this behavior? Why does cold power-on boot behave differently from debugger-triggered "Start Application"? 2. What feasible solutions can resolve the auto-boot failure after AB partition swap? Thanks for your support.
Hello@lukaszadrapa
I have tried the AB‑partition swap according to previous suggestions, but the issue still persists.
The HSE firmware version used is s32k344_hse_fw_1.5.0_2.40.
Test setup for validating AB‑swap:
Single linker script with application‑based self‑update. The application is responsible for programming the new firmware image into the passive partition.
Linker script: Only one linker script is used, and the firmware start address is always set to 0x00400000.
Workflow:
1. The application running in Partition A (logical address 0x00400000) receives new firmware over CAN. The only difference between Partition A and Partition B firmware is the LED‑blinking frequency.
2. The application programs the new firmware directly into the physical address of the passive partition (0x00600000).
3. After programming completes, the HSE_ActivatePassiveBlock() service is called.
4. The chip is then reset.
Observation:
The firmware fails to run after reset. However, when J‑Link is connected and "Start Application" is triggered from the debugger, the firmware from Partition B executes correctly.
What other root causes can lead to unsuccessful partition swap, and what are the corresponding solutions?
Regards