AnsweredAssumed Answered

Sawtooth on Reset_B K20

Question asked by Dan Vona on Feb 20, 2015
Latest reply on Feb 23, 2015 by Tony Gambacurta

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.


Outcomes