[SOLVED] "Failed to get CPU status after 4 retries" message caused by STOP mode Kinetis KL14

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] "Failed to get CPU status after 4 retries" message caused by STOP mode Kinetis KL14

    I'm getting this message every time I hit the "WFI" instruction and hit the break button on IAR.

    The CPU is a Kinetis KL14Z32XXX4, Cortex-M0. I'm using a Segger J-Link Ultra+ (but I was seeing this same error when using a Freedom KL25 board in J-Link mode). Communication mode is SWD. IAR version is 7.40.

    This obviously makes it difficult to debug a device in a low-power application. Any help available?

    Below is the debug log:
    Thu Aug 27, 2015 11:26:27: Loaded macro file: C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.2\arm\config\debugger\
    Freescale\KLxx.dmac
    Thu Aug 27, 2015 11:26:28: Logging to file: C:\Projects\svnInSync\KML\UniversalRedesignFW\trunk\cspycomm.log
    Thu Aug 27, 2015 11:26:28: JLINK command: ProjectFile = C:\Projects\svnInSync\KML\UniversalRedesignFW\trunk\settings\
    ApplicationKML_Debug.jlink, return = 0
    Thu Aug 27, 2015 11:26:28: Device "MKL14Z32XXX4" selected.
    Thu Aug 27, 2015 11:26:28: DLL version: V4.96l, compiled Feb 25 2015 10:24:11
    Thu Aug 27, 2015 11:26:28: Firmware: J-Link Ultra V4 compiled Apr 10 2015 10:59:25
    Thu Aug 27, 2015 11:26:28: Selecting SWD as current target interface.
    Thu Aug 27, 2015 11:26:28: JTAG speed is initially set to: 32 kHz
    Thu Aug 27, 2015 11:26:29: Found SWD-DP with ID 0x0BC11477
    Thu Aug 27, 2015 11:26:29: Found SWD-DP with ID 0x0BC11477
    Thu Aug 27, 2015 11:26:29: Found Cortex-M0 r0p0, Little endian.
    Thu Aug 27, 2015 11:26:29: FPUnit: 2 code (BP) slots and 0 literal slots
    Thu Aug 27, 2015 11:26:30: Kinetis L-series (setup): Disabling watchdog.
    Thu Aug 27, 2015 11:26:30: Hardware reset with strategy 2 was performed
    Thu Aug 27, 2015 11:26:30: Initial reset was performed
    Thu Aug 27, 2015 11:26:30: J-Link: Flash download: Flash programming performed for 1 range (1024 bytes)
    Thu Aug 27, 2015 11:26:30: J-Link: Flash download: Total time needed: 0.221s (Prepare: 0.080s, Compare: 0.064s, Erase: 0.011s, Program:
    0.029s, Verify: 0.004s, Restore: 0.031s)
    Thu Aug 27, 2015 11:26:30: 32765 bytes downloaded (48.78 Kbytes/sec)
    Thu Aug 27, 2015 11:26:30: Loaded debugee: C:\Projects\svnInSync\KML\UniversalRedesignFW\trunk\Debug\Exe\c.out
    Thu Aug 27, 2015 11:26:30: Kinetis L-series (setup): Disabling watchdog.
    Thu Aug 27, 2015 11:26:30: Software reset was performed
    Thu Aug 27, 2015 11:26:30: Target reset

    The post was edited 1 time, last by Chris.Burrus ().

  • Actually, I was wrong. Once the cpu goes into a halted state (via the "WFI" instruction) the "Failed to get CPU status..." message happens automatically. Is the J-Link Ultra+ not capable of debugging CPUs in sleep/halt modes??

    Is there a way to force the J-Link into using OpenSDA mode? I know that works...

    EDIT :

    Also, I have downloaded the Segger J-Link Debugger software which has the same results. It cannot debug the halted CPU.



    EDIT 2 :

    I've also tried with v5.0 of the Segger DLL.
    Thu Aug 27, 2015 15:54:55: Loaded macro file: C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.2\arm\config\debugger\
    Freescale\KLxx.dmac
    Thu Aug 27, 2015 15:54:55: Loaded macro file: C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.2\arm\config\flashloader\
    Freescale\FlashKLxx.mac
    Thu Aug 27, 2015 15:54:56: Logging to file: C:\Projects\svnInSync\KML\UniversalRedesignFW\trunk\cspycomm.log
    Thu Aug 27, 2015 15:54:56: JLINK command: ProjectFile = C:\Projects\svnInSync\KML\UniversalRedesignFW\trunk\settings\
    ApplicationKML_Debug.jlink, return = 0
    Thu Aug 27, 2015 15:54:56: Device "MKL14Z32XXX4" selected.
    Thu Aug 27, 2015 15:54:56: DLL version: V5.0l, compiled Aug 7 2015 15:52:45
    Thu Aug 27, 2015 15:54:56: Firmware: J-Link Ultra V4 compiled Jul 6 2015 16:42:08
    Thu Aug 27, 2015 15:54:56: Selecting SWD as current target interface.
    Thu Aug 27, 2015 15:54:56: JTAG speed is initially set to: 32 kHz
    Thu Aug 27, 2015 15:54:56: Found SWD-DP with ID 0x0BC11477
    Thu Aug 27, 2015 15:54:56: Found SWD-DP with ID 0x0BC11477
    Thu Aug 27, 2015 15:54:56: Found Cortex-M0 r0p0, Little endian.
    Thu Aug 27, 2015 15:54:56: FPUnit: 2 code (BP) slots and 0 literal slots
    Thu Aug 27, 2015 15:54:57: CoreSight components:
    Thu Aug 27, 2015 15:54:57: ROMTbl 0 @ F0002000
    Thu Aug 27, 2015 15:54:57: ROMTbl 0 [0]: FFFFE000, CID: B105900D, PID: 000BB932 MTB-M0+
    Thu Aug 27, 2015 15:54:57: ROMTbl 0 [1]: FFFFF000, CID: B105900D, PID: 0008E000 MTBDWT
    Thu Aug 27, 2015 15:54:57: ROMTbl 0 [2]: F00FD000, CID: B105100D, PID: 000BB4C0 ROM Table
    Thu Aug 27, 2015 15:54:57: ROMTbl 1 @ E00FF000
    Thu Aug 27, 2015 15:54:57: ROMTbl 1 [0]: FFF0F000, CID: B105E00D, PID: 000BB008 SCS
    Thu Aug 27, 2015 15:54:57: ROMTbl 1 [1]: FFF02000, CID: B105E00D, PID: 000BB00A DWT
    Thu Aug 27, 2015 15:54:57: ROMTbl 1 [2]: FFF03000, CID: B105E00D, PID: 000BB00B FPB
    Thu Aug 27, 2015 15:54:57: Hardware reset with strategy 0 was performed
    Thu Aug 27, 2015 15:54:57: Initial reset was performed
    Thu Aug 27, 2015 15:54:57: ----- Prepare hardware for Flashloader -----
    Thu Aug 27, 2015 15:54:57: 768 bytes downloaded (11.90 Kbytes/sec)
    Thu Aug 27, 2015 15:54:57: Loaded debugee: C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.2\arm\config\flashloader\
    Freescale\FlashKLxx4K.out
    Thu Aug 27, 2015 15:54:57: Target reset
    Thu Aug 27, 2015 15:54:58: Unloaded macro file: C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.2\arm\config\flashloader\
    Freescale\FlashKLxx.mac
    Thu Aug 27, 2015 15:54:58: Downloaded C:\Projects\svnInSync\KML\UniversalRedesignFW\trunk\Debug\Exe\c.out to flash memory.
    Thu Aug 27, 2015 15:54:58: Hardware reset with strategy 0 was performed
    Thu Aug 27, 2015 15:54:59: 32765 bytes downloaded into FLASH (17.53 Kbytes/sec)
    Thu Aug 27, 2015 15:54:59: Loaded debugee: C:\Projects\svnInSync\KML\UniversalRedesignFW\trunk\Debug\Exe\c.out
    Thu Aug 27, 2015 15:54:59: Hardware reset with strategy 0 was performed
    Thu Aug 27, 2015 15:54:59: Target reset

    The post was edited 3 times, last by Chris.Burrus ().

  • Ok. So this is the culprit :

    C Source Code

    1. // *****************************************************************************
    2. // VLPS (Very Low Power Stop)
    3. // ARM core enters DeepSleep Mode
    4. // ARM core is clock gated (HCLK = OFF)
    5. // NVIC is disable (FCLK = OFF)
    6. // WIC is used to wake up from interruptions
    7. // Platform and peripheral clock are stopped
    8. // MCG module can be configured to leave reference clocks running
    9. // On chip voltage regulator is in a mode that supplies only enough power to
    10. // run the MCU in a reduced frequency
    11. // All SRAM is operating (content retained and I/O states held)
    12. // *****************************************************************************
    13. void PowerMode_VLPS(void)
    14. {
    15. volatile unsigned int dummyread;
    17. /* Write to PMPROT to allow LLS power modes this write-once
    18. bit allows the MCU to enter the LLS low power mode*/
    19. SMC_PMPROT = SMC_PMPROT_ALLS_MASK;
    20. /* Set the STOPM field to 0b011 for LLS mode */
    21. SMC_PMCTRL &= ~SMC_PMCTRL_STOPM_MASK;
    22. SMC_PMCTRL |= SMC_PMCTRL_STOPM(0x3);
    23. /*wait for write to complete to SMC before stopping core */
    24. dummyread = SMC_PMCTRL;
    25. dummyread++;
    27. /* Now execute the stop instruction to go into LLS */
    28. /* Set the SLEEPDEEP bit to enable deep sleep mode (STOP) */
    29. SCB_SCR |= SCB_SCR_SLEEPDEEP_MASK;
    31. asm("WFI");
    32. }
    Display All


    Most specifically it's the setting of the SLEEPDEEP bit, in the SCB SCR register.

    Is the J-Link not capable of handling Very Low Power Stop (VLPS) mode on the Cortex-M0?

    I can comment out the line where the SLEEPDEEP mask is set, and the error no longer occurs. Unfortunately, my code no longer works since the NVIC is shut down, and the LLWU unit is expected to detect button presses and other external interrupts.

  • Hello Chris,


    sorry for the delay in response. In general, we try to answer each question within 1-2 days.
    Still, i have to mention that this is *not* a support forum with claim to get support from engineers.
    As (from what i can see) you are still in support (2 years for J-Link Ultra+), you are free to request support via E-Mail, which will be handled with much higher priority than this forum.

    Regarding your problem:
    Depending on the device, the debug unit is turned off in low power mode. In this case, J-Link cannot continue debugging.
    Is the J-Link not capable of handling Very Low Power Stop (VLPS) mode on the Cortex-M0?
    At the moment, J-Link is no capable of handling VLPS. Better handling of sleep modes will be available within the next two months.

    Best regards,
    Niklas
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • Hi all,

    Quick update on this topic:
    The improved low power mode debugging handling has been introduced in V5.10 of the J-Link software: segger.com/jlink-software.html
    Further information regarding this topic can be found in the J-Link user manual (UM08001) chapter "Low Power Debugging".


    Best regards
    Erik
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.