- 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
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
I’m sorry for delayed response.
Here are some typical issues:
When you run HSE_ActivatePassiveBlock() and when you reset the device, it takes about 1s until HSE is ready to accept new service requests. That’s because HSE takes a backup of HSE firmware to passive partition. HSE_STATUS_INIT_OK flag in FSR register is set once the operation is completed. So, it’s not possible to use HSE until it’s finished. Sometimes this is the reason of troubles.
This has been optimized in firmware versions 0.2.55.0 and newer and the firmware is copied to passive partition only if it is updated. If it is still the same, HSE will skip this operation and the swap is much faster.
Then I recommend to read description in HSE Firmware reference manual rev. 2.7 in section:
“14.6.5 Synchronizing flash read/write access between HSE and application core”:
https://www.nxp.com/webapp/sd/collateral/1765990353647716033651?version=2.7
There are tables 149, 150 and 151 where you can find details about typical scenarios.
In your case: when HSE takes backup of itself to passive partition, it is not possible to access flash block 3 because HSE performs flash operations on that block.
Also you can’t perform flash operations on block 1 because HSE firmware is running from this block.
Another thing is that if HSE is running, it is not possible to change HSE_CLK. This can be a problem after the swap when HSE is running about 1s after the reset.
When changing HSE_CLOCK, HSE must be in idle state. It is not possible to change the clock while HSE is running. This can lead to unpredictable behavior. It is explicitly mentioned in the S32K3 reference manual:
“Before configuring HSE_CLK, you must wait for the SBAF to enter WFI by reading core status register of HSE CPU (PRTN0_CORE2_STAT).”
This could be a problem when using older versions of RTD drivers because the drivers did not check mentioned status register.
This check was implemented to RTD version 5.0.0 and higher. If you have older version, it’s up to user to poll the WFI before clock initialization. So, this may be also the reason why it is failing.
Hello，bro
I also encountered the same problem. Could you please tell me how you solved it?