MKL03Z8 unresponsive after entering vlls3

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MKL03Z8 unresponsive after entering vlls3

Jump to solution
577 Views
PeterK
Contributor III

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

0 Kudos
1 Solution
465 Views
PeterK
Contributor III

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

View solution in original post

0 Kudos
1 Reply
466 Views
PeterK
Contributor III

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

0 Kudos