Sawtooth on Reset_B K20

[dvona]

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.

[tonygambacurta · Accepted solution]

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.