- 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
- :
- 2412218_en-US
2412218_en-US
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
2412218_en-US
2412218_en-US
Hi NXP Team,
Platform details:
- SoC: i.MX8QXP C0, custom board based on MEK reference
- BSP: NXP Linux 6.6.3 [state exact tag, e.g. lf-6.6.3-1.0.0], Yocto Scarthgap
- SCFW version: [run scu_rm / check boot log — paste version]
- SECO/AHAB: [enabled/not enabled, version]
- U-Boot: [2024.04/tag]
- Cortex-M4 (CM4_0): currently unused, no firmware loaded
- Use case: production automotive instrument cluster; A35 runs Linux/Weston HMI
Problem statement:
In production we occasionally see the A35 complex crash or hard-hang (kernel panic / lockup). Today we have no persisted crash evidence and no autonomous recovery — the cluster stays dead until a manual power cycle, and field/DV occurrences cannot be debugged. We want to implement (a) panic-log persistence across a watchdog reset using pstore/ramoops, and (b) supervision of the A35 by the CM4_0 with the ability to reset only the A35 partition.
On i.MX8QXP C0, when the system watchdog (imx-sc-wdt, handled by SCFW) fires, what type of reset is performed — full SoC/board reset or A-cluster partition reset? Is this configurable via SCFW board file or sc_pm API?
Hello,
yes, you may use a virtual watchdog managed by the SCFW to reset the partitionSC_TIMER_WDOG_ACTION_PARTITION behavior is what you want it resets only the Linux/A35 partition.
Also, there is a way to achieve the same effect from CM4_0 firmware directly by calling sc_pm_reset_partition() on the A35 partition via the SCFW sc_pm API, which gives the CM4_0 full supervisory control independent of the watchdog mechanism.
You can find more information about this on the SCFW porting guide for the specific version that you are using.
Best regards/Saludos,
Aldo.