Hello,
I have been tinkering with the MKL03Z8.
The IDE has been IAR with the TI MPS432 Launchpad, in cmsis-dap mode, and the STM32 Discovery Kit as debugger probes. Everything has been fine for a month or two with "countless" downloads and debugging sessions. Both debuggers worked good with the Launchpad having slightly better functionalty whereas the STM32 was a little faster at downloading. The application main structure is the kind where most time is spent sleeping (seconds) , then waking up briefly, take some ADC measurements, and then back to sleep. VLPR -> VLPS with LPTMR clocked by LPO as wake-up source. It all worked well and battery economy was good (4-6 uA).
I was then testing VLLS modes to see if battery economy could become even better and vlls3 did shave off another 1.5uA.
Problem was, that when I finished that debugger session, I could no longer connect to target.
"Fatal Error: Failed to connect to CPU".
This is with the MSP432 Launchpad debugger. The STM32 Disco has an equivalent message.
Same problem in all debugger RESET modes: System, Software, Hardware.
The STM32 Disco has an extra RESET mode which looked promising (Connect Under Reset), but no luck.
All 5 HW connections between debugger probe(s) and target have been and are direct with no resistors or caps.
+3V, GROUND, RST, SWDIO, SWDCLK. From time to time I've had a 4.7uF cap between +3V and Ground.
(before the problem started I often had to disconnect RST in order for a download to happen. Dunno why, ignored it.)
Most of the time I've had the debugger(s) "Leave target running".
Varying the SWD clock: all combinations tried, same result.
Mass erase: same.
As for the code in the (unresponsive) target MKL03Z8:
NV_FOPT = FTFA_FOPT = 0x0A. So slow reset into VLPR, NMI_b pin disabled, BOOTPIN_OPT=1 (flash boot).
NV_FOPT is the only NV_ byte that has been modified, so I guess there should not be an issue with flash security.
I am not sure if interrupts are on or off. Perhaps permanently off. Coming out of RESET (not POR) code may never set ACKISO or restore I/0 pins.
So, does anybody know how I can connect the IDE and debugger to this target again?
Or, alternatively, forgetting this specific MKL03Z8, is there something I can do to make sure that I will always be able to recover from something like this? Like different NV_ byte(s), different FTFA_FOPT or something else?
Any help will be appreciated.
Thanks,
Peter Kobl
Solved! Go to Solution.
I found a way to do this
with inspiration from thread https://community.nxp.com/thread/445747
thanks
Setup:
IAR IDE (EWARM),
MSP432 XDS110 Launchpad debugger in cmsis-dap mode. Option: CMSIS-DAP>Setup>Reset set to "Hardware",
5 wires straight from debugger to target (+3V, GND, SWDCLK, SWDRST, and SWDIO).
When failing the "Fatal error ,," message would pop up about 4 seconds "into" the download.
But with an extra wire connecting GND and SWDRST, and having initiated the download, and then pulling the wire out again after 2-3 seconds, the download continues and succeeds. Target could then be used in the usual ways.
Hopefully this may be helpful to somebody else.
-- Peter Kobl
I found a way to do this
with inspiration from thread https://community.nxp.com/thread/445747
thanks
Setup:
IAR IDE (EWARM),
MSP432 XDS110 Launchpad debugger in cmsis-dap mode. Option: CMSIS-DAP>Setup>Reset set to "Hardware",
5 wires straight from debugger to target (+3V, GND, SWDCLK, SWDRST, and SWDIO).
When failing the "Fatal error ,," message would pop up about 4 seconds "into" the download.
But with an extra wire connecting GND and SWDRST, and having initiated the download, and then pulling the wire out again after 2-3 seconds, the download continues and succeeds. Target could then be used in the usual ways.
Hopefully this may be helpful to somebody else.
-- Peter Kobl