K8x MCU Reset Fails (project execution fails before hitting initial breakpoint)

[deniscollis]

I need some troubleshooting ideas.

I have a custom board with K82, SDK2.8.0, MCUXresso IDE v11.7.1_9221, Segger J-Link Compact. There's a debug console on LPUART4.  

Execution fails before hitting initial breakpoint. Debugger opens view on startup_mk82f25615.c:

If I hit pause:

If I then disconnect J-Link and power cycle the board it still does not run (my LED heartbeat indicator is dead).

If I then load the .bin file with J-Link Commander (V7.86e), I get:

J-Link>loadbin C:\Projects\sspm-cl-v1\DTE_L2\sspm-cl-v1.bin 0
'loadbin': Performing implicit reset & halt of MCU.
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.
Reset: SYSRESETREQ has confused core.
Found SW-DP with ID 0x2BA01477
DPIDR: 0x2BA01477
CoreSight SoC-400 or earlier
AP map detection skipped. Manually configured AP map found.
AP[0]: AHB-AP (IDR: Not set)
AP[0]: Skipped. Could not read CPUID register
Attach to CPU failed. Executing connect under reset.
DPIDR: 0x2BA01477
CoreSight SoC-400 or earlier
AP map detection skipped. Manually configured AP map found.
AP[0]: AHB-AP (IDR: Not set)
AP[0]: Skipped. Could not read CPUID register
Could not find core in Coresight setup
Reset: Using fallback: VECTRESET.
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.VECTRESET.
Reset: VECTRESET has confused core.
Reset: Using fallback: Reset pin.
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via reset pin
Reset: VC_CORERESET did not halt CPU. (Debug logic also reset by reset pin?).
Reset: Reconnecting and manually halting CPU.
Found SW-DP with ID 0x2BA01477
DPIDR: 0x2BA01477
CoreSight SoC-400 or earlier
AP map detection skipped. Manually configured AP map found.
AP[0]: AHB-AP (IDR: Not set)
AP[0]: Skipped. Could not read CPUID register
Attach to CPU failed. Executing connect under reset.
DPIDR: 0x2BA01477
CoreSight SoC-400 or earlier
AP map detection skipped. Manually configured AP map found.
AP[0]: AHB-AP (IDR: Not set)
AP[0]: Skipped. Could not read CPUID register
Could not find core in Coresight setup
T-bit of XPSR is 0 but should be 1. Changed to 1.
AfterResetTarget()
Downloading file [C:\Projects\sspm-cl-v1\DTE_L2\sspm-cl-v1.bin]...
HandleBeforeFlashProg() start
HandleBeforeFlashProg() end - Took 4us

****** Error: Failed to preserve target RAM @ 0x1FFF0000-0x2002FFFF.
Failed to prepare for programming.
Unspecified error -1
J-Link>

[deniscollis · Accepted solution]

This was caused by the Flash Option (FOPT) Register config in startup_mk82f25615.c.

The board has a PN5180 NFC Frontend that uses the NMI pin on PTA4 for its IRQ.  This pin is also used for the K8x boot, but should not be.  The startup_MK82F25615c template used by the SDK sets the FOPT Config to 0x3D, which has

• NMI_DIS bit is set, (NMI pin/interrupts reset default to 'enabled')
• BOOTPIN_OPT is not set (which forces Boot from ROM is BOOTCFG0 is asserted - requires RESET pin enabled)

Changing to 0x3B:

• NMI is not set (NMI Interrupts are always blocked)
• BOOTPIN_OPT is set (requires BOOTSRC_SEL to be set)
• BOOTSRC_SEL is 00b (Boot from Internal Flash)

Which Stabilizes the debug environment so that it behaves as expected.

This also fixes reset issues like watchdog or __NVIC_SystemReset() not working. (See: NVIC_SystemReset not working on MK82 )  

[deniscollis]

Narrowing down the issue.

I have found that the MCU fails to reset only if, on a previous session, functions are called that are in a library archive (libxxx.a). This is library provided by a third party - no source code - so are obviously not 'debuggable'.

However, in the normal operational (not debug) environment, the board appears to run without any issues. 

[deniscollis]

The issue appears to resolve when I unplug the Serial-to-USB cable connecting the UART to the PC and power-cycle the board.  After restarting MCUXpresso and restarting the debug, execution then stops at the first statement in main(), as expected.  I can then reconnect the Serial-to-USB cable, and resume execution.

Does anyone know why this could be so, and how to fix it?  

[Miguel04]

Hi @deniscollis 

I'm glad you found a workaround, I've been looking for the root cause and it could be caused by many debug sesions active, some hardware issues on your custom board, the mcu is not respondig to the reset or the debuger firmware version.

Best Regards, Miguel.

[deniscollis]

Hi Miguel. I have posted a support ticket with Segger. I'll revert with their findings. Thanks.