- 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
- 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
-
- 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
-
- 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
-
- Home
- :
- General Purpose Microcontrollers
- :
- Kinetis Microcontrollers
- :
- MKL26 - Do not exit from Run Mode
MKL26 - Do not exit from Run Mode
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi everybody,
I'm working with a MKL26 in Kinetis Design Studio 3.2.0. I use a Segger J-Link as debugger. This is my very first project with Kinetis and MKL26/ARM.
I noticed that when I remove the Segger J-Link the MCU exits from the Run Mode. If Segger is connected then the MCU stays in Run Mode. I found this behaviour in the reference manual: "1. If debug is enabled, the core clock remains to support debug."
What I didn't find is how to configure the MCU to remain continuously in Run Mode.
I have a complex system (with other programable devices) and the MKL26 performs some very simple but critical safety functions and it MUST NOT exit from RUN mode. No transition to WAIT or STOP or any other mode is allowed. It must work continuously.
I'm pretty sure I miss something in documentation, but I simply cannot find hot to set it continuously to RUN mode.
Thank you for you input!
Paul
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I got it. It had nothing to do with Run mode.
External perturbations generated a reset signal on RESET_B port. When Segger was connected, it holds the reset level correctly. We have no pull-up/down on the PCB for RESET_B and the external perturbation were driving the MCU in reset.
I disabled the RESET control and problem solved. At least the problem with what I thought that is a change in Modes.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What are you currently using for your reset circuit? I'm hoping you're not going to say an RC time delay network.
If this application performs "critical safety functions" then you should ensure that you are monitoring power to the MCU and handling reset appropriately. Look at using a power line supervisor for reset (I use the APX803S-31SA-7) as this will give you start up delay and hold the MCU in reset if you have a +3V3 rail problem.
It costs about 3x an RC network, but it's worth it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I got it. It had nothing to do with Run mode.
External perturbations generated a reset signal on RESET_B port. When Segger was connected, it holds the reset level correctly. We have no pull-up/down on the PCB for RESET_B and the external perturbation were driving the MCU in reset.
I disabled the RESET control and problem solved. At least the problem with what I thought that is a change in Modes.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If this is a safety critical device then the cause of the problem needs addressed at the source, not covering up the symptom by disabling reset. Lets say the problem is the power source, it could just as easily corrupt RAM while things are running just as well as forcing an undesired mode change.
