AnsweredAssumed Answered

MKL03Z8 unresponsive after entering vlls3

Question asked by Peter Koblauch on Mar 7, 2017
Latest reply on Mar 8, 2017 by Peter Koblauch

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

Outcomes