SM320F2801 Resetting itself

Richard,

The periodic reset is most likely being caused by the watchdog timer.  You say "The oscillator is stead at 100 MHz."  After running some numbers, I conclude that you are feeding a 100 MHz clock signal directly into the CLKIN pin.  The WD will timeout after 131072 OSCCLK (i.e., CLKIN) cycles, which equates to 763 Hz.  This is basically the 757 Hz that you cite as the reset periodicity.  Also, per the device datasheet, the RSTn low pulse duration from a reset is 512*tc(CI), where tc(CI) is the input clock period (1/100MHz in your case).  Do the math and you get 5.12 us.  This is the same thing you report as observing for the RSTn low pulse.  So, the WD is causing your reset.  This is normal.

The question now is what the issue is with programming the device.  How are you trying to program it?  Are you using JTAG and the CCS debugger?

Regards,

David

Hi David,

Thanks for your response.

From everything I've read here, that's what I concluded.  I just don't understand why.  We've only got two units that do this, it's only happened on the latest release of the board, and we've been building these things for over 2 years using the same code and the same tools.

We're programming them through JTAG and the CCS debugger.  When we try to program the device, CCS says it cannot communicate with the device because it is either locked or not connected.  We replaced the processor in each of the units and got the same response.  I assumed it was because of the repetitive resets.

Is there any other data I can get you that might help narrow this down?

Richard,

From what you say, it sounds like there is something wrong with those two specific boards.  You changed the '2801 device on each board, and still have the same problem.  So, the problem would seem to be with the boards, and not the devices.  Could be anything.  Maybe a shorted trace on the JTAG signals for example.

Normally people would do what the QC guys call a A-B-A swap.  That is, take a known good board, and swap the device with the known bad board.  Then see what is still working.  This would confirm that the device on the original bad board is OK if the good board is still working after the swap.  It also would show if the "bad" board is actually bad since you've put a known good device on it.  You've sort of done this, but not really.  You put a new device on the bad board, but you didn't say if you that device was known good.  Anyway, I ramble...

The first problem here is that JTAG cannot connect.  You need to solve this first (and then the programming problem will likely go away).  Check the RTSn signal.  Make sure it is high (not in reset).  Check the signal at the device pin.  If you're using the BGA package, do the best you can.  Check the signal as close to the ball as possible.  Check the XCLKOUT signal.  Make sure it is active.  It should be XCLKIN/8 while the device is in reset, and after reset is released.  Check core and I/O voltage levels.  Just my thoughts.  You're going to have to debug the board to find the problem.

Regards,

David

Hi David,

I'm sure the problem is with our boards but I'm trying to understand the chip behavior better to understand where on my board to look.  The first question I have is why would the chip do constant resets?  Can the JTAG cause this?  Shorted GPIO?  I'm trying to narrow the problem down to something less than 100 inputs.  :^)  I was thinking that the reason the JTAG wouldn't connect is because the chip is doing repetitive resets.  Is the repetitive resets normal behavior until programmed?  Does the JTAG somehow override this and after programming I'm good? I've got hundreds of possibilities and thousands of pages of documents to read with no guarantee I'll find the answer.  I'm turning to you guys to help me try to narrow down my search.  I've done a lot of debug work already but the only thing I can find wrong is that the processor is resetting itself over and over.  If I understand better why this happens, it will help me narrow down this search.

Anyway, what I do know is that core and IO power is fine.  We cannot remove a processor from a board without destroying it because we don't have the proper equipment.  The best I can do is just replace the processor which we've done on both units.  The XCLKOUT is 12.5 MHz (XCLKIN/8).  I just checked. 

What is the RTSn signal?  I just looked and don't see it on the processor.  Could this be the same as TRST* from the JTAG?

Richard,

The WD is running out of reset.  Unless JTAG takes control of the device, or unless you have code in the device that disables or otherwise manages the dog, the WD will reset the device.  The device will then come out of reset, WD will start running again, and the resets will just keep happening.

What I meant by RSTn signal is the XRSn (reset) signal.  I called it the wrong thing.  Too many different processor with too many different names for this pin.

If you have XCLKIN=100 MHz, I'd expect XCLKOUT signal to be 100MHz/8 by default.  So, something seems strange here.

- David

Thanks David,

I see I didn't edit fast enough.  :^)  I just checked and indeed XCLKOUT is 12.5 MHz as you stated.  Thanks for the understanding of the expected behavior.  I'll see if I can find out what is going on with the JTAG next.

The original waveform in this thread is the XRSn signal.  Sorry, I called it RESETL because that's what we labeled it on our drawings.  DOH!

Anyway, I'll start looking closer to the JTAG area.  It appears you've already narrowed down my search from 100 pins to 8.  :^) 

Check the PD pin on the JTAG header with the emulator not connected to the board.  It should be 3.3V.  This is the presence detect pin that tells the debugger that the board is powered and present.

Also, what is the error message CCS is giving you?

- David

Thanks David,

The above was not the cause of the problem but helped me understand the expected behavior so I could find the problem.  Before I was just chasing my tail thinking the WD resets were abnormal under these conditions.  It turned out someone had removed a component that supplies 3.3VA.  Everything is working fine now.  You can close this ticket now.

Thanks again (immensely) for your assistance,

Rick