- NXP 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
- MCX Microcontrollers
- S32G
- S32K
- S32V
- MPC5xxx
- Other NXP Products
- Wireless Connectivity
- 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
-
- 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
- MCUXpresso Training Hub
-
- 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
-
- Home
- :
- Product Forums
- :
- S12 / MagniV Microcontrollers
- :
- MC9S12X unexpected shutdown after continuous UDS service request
MC9S12X unexpected shutdown after continuous UDS service request
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
MC9S12X unexpected shutdown after continuous UDS service request
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I got a strange but could be easilly replicated issue on MC9S12X.
We are working on a case in which our ECU is continuous processing some kind of data acquisition request from a diagnostic tool. MCU would be shut down unexpectedly and failed to reboot in a non-certain period (mins to hours) with LDO module working and related voltages (VCC and VDD) still remaining 5V. A standard 40us voltage drop-off on MCU reset pin could be observed with oscillator before this happened. When I attached debugger to to MCU at this time, I saw the PC pointer would always point to several same addresses (0x0003 and 0xFF12 as I noticed), and the COPCTL registor value became 0 instead of 0x47, which stands for a normal mode internal WDT with frequence set to 2^24. A manual STG on reset pin would solve this problem.
In my understanding, if we failed to clear the WDT timer (set ARMCOP = 0x55 and 0xAA as stated in datasheet), MCU would go to a predefined address in vector table (0xFFFE) then get itself rebooted, and I tried to set ARMCOP to other values in my code to check if internal WDT is enabled. It turne out MCU could be reset normally this way.
This issue have been confusing me for a while. I would appreciate if there is anyone who can help.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- if we failed to clear the WDT timer (set ARMCOP = 0x55 and 0xAA as stated in datasheet), MCU would go to a predefined address in vector table (0xFFFE) then get itself rebooted, and I tried to set ARMCOP to other values in my code to check if internal WDT is enabled. It turne out MCU could be reset normally this way.
COP on S12(X) has dedicated reset vector, not FFFE, but FFFA. Unless you do serious mistake and attach too big capacitor on /RESET pin, or perhaps using push-button reset chip, which could sense /RESET pulled low by CPU and extend /RESET low pulse, fooling this way MPU to not distinguish any more internal reset sources with external one, then yes, MCU would take reset vector at FFFE, no matter what causes reset.
The sequence of such reset is not like you write, please study documentation. In shot MCU is reset, including all (if not the most) of registers, then on reset specific reset vector is taken and CPU jumps to it.
- When I attached debugger to to MCU at this time, I saw the PC pointer would always point to several same addresses (0x0003 and 0xFF12 as I noticed), and the COPCTL registor value became 0 instead of 0x47
Debugger could fool you. First of all, on reset breakpoints and the rest of debug HW is reset as well, so you shouldn't expect any breakpoint hit. If you simply click connect in debugger (assuming you don't allow it to reupload code), usually it resets CPU again into normal single chip mode, so you shouldn't expect and meaningful register state, reflecting what went wrong. To connect without reset, you should use, eh, IIRC CodeWarrior debugger calls it Hotplug, which wouldn't reset target and try to BDM connect without mode change.
Unlike CME and COP reset, which can be distinguished by vector taken (don't forget to remove cap on /RESET etc), other reset sources, ILAD, LVR, POR can be distinguished reading bits in CRGFLG.
lama
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Hard to answer. Some hints.
If you use COP be sure that each loop processes 0x55, 0xAA sequence.
There is an example XEP100-CRG-COP-CW47.ZIP at https://community.nxp.com/t5/S12-MagniV-Microcontrollers/LAMA-s-S12XE-unofficial-examples/ta-p/11007...
I would suggest to rad comment in the main.c file carefully.
Create a interrupt catcher to check whether some interrupt is not initialized but launched without service routine.
An example…
I have not checked whether it is related to XE but principle is ok.
Check stack, it is usually done by filling stack (allocated size in the prm file) with FF (you can allocate special space for stack and fill it with FILL command if you use CodeWarrior) and checking how deep I go into it. There is no special function how to check it so the method is up to you.
If the stack is located above RAM data then it can destroy them if underflows. If the stack is put to the bpttom of the RAM then it can underflow out of RAM space
Best regards,
Ladislav
