1) Slowed the power supply rise time by using a 10ohm resistor with a 47uF cap. On our board this gave a rise time of about 4ms which is probably more than I need but I didn't want to risk an improper POR.

2) We had a pull up resistor on the TDO line. This was removed so our board has no pull up or pull down on this line.

3) We had a pull down on the TDI line. This has been changed to a pull up.

4) We had 100ohm protection resistors to each of the JTAG pins and to the reset pin. These were all reduced to zero ohms.

We probably didn't need to do all of the above changes to make it work.

I check dieter suggested to check the errata e4949 about "Reset and Boot: Device may not exit the power on reset (POR) event correctly with fast ramp-up slew rates." Please check the power up with voltage instantaneous slew rate of VDD below 17 kV/sec. Please let us know your test result.

1) Slowed the power supply rise time by using a 10ohm resistor with a 47uF cap. On our board this gave a rise time of about 4ms which is probably more than I need but I didn't want to risk an improper POR.

2) We had a pull up resistor on the TDO line. This was removed so our board has no pull up or pull down on this line.

3) We had a pull down on the TDI line. This has been changed to a pull up.

4) We had 100ohm protection resistors to each of the JTAG pins and to the reset pin. These were all reduced to zero ohms.

We probably didn't need to do all of the above changes to make it work.

When i tried to run a KL10 that did not connect to the SWD debugger, i saw a sawtooth wave on its reset pin. This waveform is the result of K10 internal action. I could also see in phase supply current variations.

When i made the time constant of the reset pullup and capacitor smaller, i finally got it running for about 1.5 microseconds after it released the Reset pin. This happened about every 10 or 20 usec and it was enough for the debugger to connect and begin the first flash operation.

SWD debugging depends on so many factors and its a miracle how well it works once you got it running. On the other hand, there are many ways to get the Kinetis stuck. I can't really say what was wrong inside the K10. Maybe watchdog, maybe odd address, maybe SWD pin disabled, maybe a race condition. For example SWD cannot halt the Kinetis, once you have a stuck interrupt, i mean one that never gets cleared. In that case only a power cycle may help, or a reset switch. The SWD does not allow you to reset the device before it got halted.

The K10 mask 1N36B also has an erratum 4949 "Reset and Boot: Device may not exit the power on reset (POR) event correctly with fast ramp-up slew rates." that you should be aware of.

The erratum means that we have to power up the K10 slowly (risetime of some msec, for example 10 Ohm/470 uF). Then the POR works as expected and the Reset pin comes free. Another requirement is that we have a capacitor of 10 nF or more close to the reset pin in order to avoid glitches close to the switching point.

We are facing the same reset problem in our custom K70 board. The reset pin is always low. We have pulled the reset pin up externally using 10k resistor. EzPort pin is also pulled high through 10k resistor. We aren't able to trace why this persists.

Iam trying to program a custom made k60 board using mutilink jtag. Intialy for two three times it got programmed.But later it didnt get programmed. The reset_b and EZP_CS got low. So as said above i have added 10ohm resistor with a 47uF cap at the reset_b pin. Then the reset_b and ezp_cs pin got high. But still iam not being able to program it, I have pulled up the TDI pin also, the following error appears on kinetis studio