Why is RESET toggling on unprogrammed K22F?

[asfarley]

Hi,

First off - I'm aware this issue has been discussed all over the place. However, I have not found clear, consistent answers, so I'm asking the question myself to ensure all relevant context is included. 

I'm trying to program a blank K22F device on a new PCB design using a PEMicro Multilink Universal. The programmer is indicating that it doesn't see the target. Probing on the SWD lines shows some activity on SWD-IO and SWD-CLK. The RESET line is also toggling in a triangle-waveform around 10us period.

So, my questions are:

1) Does the RESET-toggling explain why the Multilink doesn't see the MCU?

2) What is the normal approach for preventing RESET from interfering with programming a blank MCU? Should the pin be pulled down? Pulled up? Controlled by the Multilink?

3) Does Peter Vlna's comment apply to my scenario?

https://community.nxp.com/message/965936?commentID=965936#comment-965936?q=reset%20toggle 

I'm not sure if he's saying that reset-toggling indicates a bricked MCU regardless of which particular part we're using, or if that issue is specific to the MPC5746C part.

Thanks.

[mjbcswitzerland · Accepted solution]

Hi Alexander

A blank K22 (and any other Kinetis without a ROM loader) will continuously reset at a fast rate (eg. 10us as you have seen). The explanation is that the processor starts (loads SP and PC from Flash) and immediately fails since the code is invalid. After 256 clock cycles the watchdog fires because it is active out of reset and needs to be disabled/programmed within this number of cycles to stop it happening. Out of reset the parts tend to run from 32kHz IRC feeding the FLL (around 20..25MHz) - 256 cycles at this speed gives your 10us.

The reset pin is driven by the processor during some 128 clocks after most resets (including watchdog reset) and then becomes an input. I think it is low drive strength when outputting a '0' and this gives the typical triangular form seen - there is often a capacitor on the line too.

If an external source keeps the reset driven low after its 128 clock cycle after it resets it has the effect of retaining the internal reset state - applying a '0' will thus hold the processor in reset and stop the repetitive reset cycling.

If you have a debugger connected it will be using the reset line to control the startup of the processor so that it can gain access to it. There is no real requirements for the reset (usually one uses just a pull-up) since the programmer will be completely controlling it by driving it.

When there are problems with the debugger not being able to control the processor into its debugging mode it may be that it is trying to work in JTAG mode when the connections are SWD, or trying to work in SWD mode when the connections are for JTAG. It may also be defective or have a bad connection somewhere. The worst case is that the JTAG/SWD interface has been disabled (by programming bad code that happens to have this pattern in the flash configuration area). This may be recoverable by EzPort mode but if this is also disabled it is really bricked.

This means that the reset line cycling is absolutely normal for a non-programmed chip and doesn't indicate that anything has gone wrong. However, if there is a chip which has been bricked it may behave identically too (consequently it doesn't really give a reliable indication of much at all). If it cycles when the debugger is trying to connect there is a problem with the debugger/cables, mode, etc...

Regards

Mark

[asfarley]

Thanks very much for the detail, Mark.

For any future readers, this was a bit of a strange one: it appears that our MCUs were bricked or somehow unable to be programmed, but after swapping with new ICs, flashing worked on the first try. So there was no physical issue with our design. 

It's interesting that the MCUs were unable to be programmed but still toggled the RESET line. I guess Mark is correct in the assessment that the RESET line toggling isn't really a clear indication of anything.