Sawtooth on Reset_B K20

dvona — Fri, 20 Feb 2015 19:22:01 GMT

I have seen other posts but the solutions do not seem to completely apply.

Here is the situation:

When I program the K20, and start it using the debugger through Segger jLink, the system runs fine and as expected.
Freestanding system (no jLink hooked up) will not start. After RESET_b goes false, something causes a Reset to occur again from inside the IC approximately 1-1.5 mSec after RESET_b goes false.
This makes the RESET_b pin exhibit a sawtooth waveform.
Shape of oscillation depends on external R and C.
With 10k ohm pullup and a 0.1uF cap, the oscillation is 630 Hz.
Problem occurs when jLink NOT hooked up. Can't cause the same failure with jLink hooked up. Therefore can't ever observe problem with debugger.
With debugger hooked up: When tracing through startup code, everything looks fine. WDOG Unlock code can't be stepped through because of constraints on timing during programming. 2 words need to be written within 20 cycles, stays unlocked for 250 cycles. Violation causes a reset. Stepping through causes a violation of these constraints. If I set a break point after this initialization code, I can execute through this code without causing a violation.
Resets do not occur when stepping through code as described, again, because it doesn't fail with jLink hooked up.
jtag signals are pulled in proper directions where specified when jLink not hooked up.
Tower K60 proto runs fine. Does not exhibit oscilation on RESET_b pin without jLink hooked up.
I compared startup code for K20 and K60. Any diferences around WDOG code were accounted for and are not an issue.
K60 system brings RESET_b signal to pin 10 of jtag connector. My k20 system brings JTAG_TRST_B to that pin. JTAB_TRST_B does not show an oscillation.
Below is a list of sources off reset for the chip. I believe I have determined that none of these is causing the problem, but, one source is probably the culprit. I have concentrated mostly on WDOG.

The following are sources of RESET:

Reset sources Description
POR reset

• Power-on reset (POR)
System resets

• External pin reset (PIN)
• Low-voltage detect (LVD)
• Computer operating properly (COP) watchdog reset
• Low leakage wakeup (LLWU) reset
• Multipurpose clock generator loss of clock (LOC) reset
• Multipurpose clock generator loss of lock (LOL) reset
• Stop mode acknowledge error (SACKERR)
• Software reset (SW)
• Lockup reset (LOCKUP)
• EzPort reset
• MDM DAP system reset
Debug reset

• JTAG reset

I'm looking for any ideas as to what might be causing this behavior.

Re: Sawtooth on Reset_B K20

tonygambacurta — Mon, 23 Feb 2015 21:40:20 GMT

First I would like to thank Dan Vona, Avnet-Freescale FAE extraordinaire for posting my problem of "Sawtooth on Reset". I have solved the problem. The cause: When creating the project using the new project wizard, at I/O support, I selected (incorrectly) "debugger console" which enables semi-hosting. It appears as though when this is selected, one cannot undue this choice later. I tried. I had to create another project where I selected "UART" for I/O support. This fixed the problem and I am on the way to finishing the project.

What appears to have been happening is that during initialization, the failing project would get to code to initialize semi-hosting, and this caused a system reset. For some reason, it didn't fail when the j-link was hooked up with the debugger running. So the system would start, reach the semi-hosting initialization, then reset, which may be viewed on the reset pin because all system resets pull the open drain reset pin low. This is a good feature because one can use it to reset outside peripherals. In addition, one can observe that a reset is occurring.

I hope this problem and solution can help others from ripping their hair out.

topic Re: Sawtooth on Reset_B K20 in Kinetis Microcontrollers

Sawtooth on Reset_B K20

Re: Sawtooth on Reset_B K20