# (Updated) Strange reset behavior with ARM9 processor

I'm working on debugging a boot problem with an Atmel AT91SAM9G20 board. Everything goes great for the first 700 ms or so. It seems that about 700 ms after reset, the processor freezes. What's curious is that the CPU drives the reset line after I release the reset button.

Here's a scope shot that shows what's going on. The yellow trace is the reset line. The first dip is the time I'm actually holding down the reset button. The second dip is, I believe, generated by the CPU.

The blue trace is serial data coming out of the CPU. The first two bursts come from the initial bootloader. The third burst is U-boot starting. The CPU stops sending out characters when the third blue burst ends.

If I'm interpreting the traces correctly, this means that the reset line is low for almost exactly the time that the processor is loading U-boot from NAND flash.

I have a few questions:

• Is this sort of CPU-controlled reset normal?
• Any suggestions about how to debug this?

A few more details: I should add that I've looked at the power rails, and they look clean. The behavior below is reproducible. I can vary the length of the initial reset dip (in yellow) by a few seconds, and the rest of the behavior happens the same way. If I plug in the JTAG cable, the behavior changes-- sometimes it boots, sometimes it doesn't, but after a few seconds, JTAG takes over, and the processor is halted.

Under JTAG, I can boot successfully. Here's what a successful JTAG-controlled boot looks like:

Note that the timescale is different, and I'm not pushing the reset button-- it's software controlled. The same reset dip occurs. In both cases, the length is around 500 ms.

Update (still baffled)

Prompted by Mr. Taffey's suggestion below, I have investigated the watchdog timer and the reset controller in more detail. The watchdog timer is in fact disabled by the first bootloader; I'm pretty sure that code is being executed because it occurs before text is sent out the debug serial port, and I can read the text successfully.

In reading about the details of the reset controller, I learned that the processor is supposed to grab control of the reset pin and pull it low for a short period. This is to ensure that other hardware on the board listening to the same line receive a long enough reset. Digging through U-boot, I found that the duration of the reset was set to 0x0D using the ERSTL field:

at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY |
(AT91_RSTC_ERSTL & (0x0D << 8)) |
AT91_RSTC_URSTEN);


The datasheet explains that the duration is set to 2^(ERSTL + 1) slow clock periods.

The reset duration looks around 500 ms long, the slow clock crystal is 32768 Hz, and Google tells me that log(0.500 * 32768) / log(2) = 14, and 0x0D + 1 = 14, so this all makes sense.

I think the real problem may be U-boot crashing; the fact that it happens just after this reset is probably irrelevant. What's confusing is why U-boot would crash only when JTAG is not connected.

Second update

I still don't know what's going awry or why JTAG makes it behave differently, but I think I have figured out a workaround (sort of). It looks like the U-boot crash is being caused in some way by the NAND flash on the board. By chance, the next revision of the board, which just arrived recently, uses a microSD card rather than NAND flash for bulk nonvolatile storage (well, there's NAND flash inside the microSD card, but you see the point).

My "solution" is just to start using the next revision of the board. U-boot also crashes on that, but for known reasons-- it is configured to look for a NAND flash, which it cannot find. Hence, it dies a fiery death.

So, problem "solved." (Expect another question shortly along the lines of "How do I make AT91Bootstrap load U-boot from a serial flash?" or "How do I make U-boot work with a microSD card?" or "Why am I doing this?")

I guess the green check mark goes to Joby for noticing that the reset line can be driven by the micro, even though it turned out to be irrelevant in the long run. Thanks for the help, all of you. I appreciate it.

Third update (about a week later)

I've been mostly working on other stuff recently, but I did figure out what the problem was eventually. My last mystery I summarized above as:

What's confusing is why U-boot would crash only when JTAG is not connected.

In fact, it turns out that I was mistaking U-boot failing to send characters out the debug serial port for U-boot crashing. I still don't understand the details, but I've discovered that it's not JTAG that makes U-boot work-- it's a common ground between my circuit and the USB host of my PC, which JTAG was providing, because it runs through the USB port. In fact, U-boot was working fine the entire time, but whenever JTAG was disconnected, the RS-232-to-USB level shifter I had breadboarded would stop working, the serial port would fail, and I would assume U-boot was dead. In reality, I discovered that I could, for example, still type ping commands and see the ICMP packets produced, even though my characters weren't echoed on the terminal.

I don't understand exactly what was going wrong, but I don't really care-- I can easily find another way to read the serial port, and in the short term, I can just make the connection to USB ground with a wire.

Thanks for the help, all.

• "Interesting"... that's all I have to say. – Kellenjb Nov 17 '10 at 2:44
• probably a dumb question but your reset circuit (the button) does have a pull up resistor on it right? I mean when the button isn't pressed the reset pin isn't left to float. In addition you could also try a debounce cap on the reset button to rule out odd behavior due to bouncing of the reset line. – Mark Nov 17 '10 at 5:25
• (Not a dumb question-- it was one of the first things I checked.) Yeah, there's a pull-up on the button. There's no debouncing cap, but I've looked closely at the rising edge, and it's not bouncing detectably. The error occurs almost 1 second after I release the button, so I think I can rule that out. – pingswept Nov 17 '10 at 15:09
• I'd probably start ripping code out of u-boot to find out where it crashes... Perhaps your JTAG adapter does a reset then halts the CPU for a while - giving something else on the board time to powerup properly – Toby Jaffey Nov 17 '10 at 16:26
• JTAG is affecting it, this just tells you for sure you should be able to find something related in the uboot code. – Kortuk Nov 17 '10 at 18:13

Looking at the datasheet:

14.3.4.5 Watchdog Reset The Watchdog Reset is entered when a watchdog fault occurs. This state lasts 3 Slow Clock cycles.

When in Watchdog Reset, assertion of the reset signals depends on the WDRPROC bit in WDT_MR: If WDRPROC is 0, the Processor Reset and the Peripheral Reset are asserted. The NRST line is also asserted, depending on the programming of the field ERSTL. However, the resulting low level on NRST does not result in a User Reset state.

Could it be that the watchdog is firing and driving the reset line?

• The next thing I was going to go read was about the watchdog timer, they can cause odd problems, but I was not sure if the JTAG would disable the Watchdog and cause the problem to stop. – Kortuk Nov 17 '10 at 15:45

This may be a long shot. On a much lower end microcontroller, a PIC, I have helped people with strange resets many time due to a low voltage programming pin being enabled.

when a programmer is connected it holds lines similar to this at a set voltage, when the programmer was disconnected they could float easily. On one project when the device crossed over metal it would reset. They did not check LVP when I asked them to, they worked for 2 more weeks and then disabled it and the problem was solved.

• I don't think this is a long shot at all. It may not be LVP or similar pin, but any input floating. We've had a PowerPC go dead with general I/O input floating just because the input's level would be checked early on in the code. – Andrey Nov 17 '10 at 13:26

Are the JTAG lines af any device connected to things they shoudn't be ?

Like, say address bus lines ?

(It took months to debug that one time.)

• Good idea. I just checked over the schematic and the PCB layout. I don't see any accidental address line crossings or misconnections. I did notice that the JTAG connector is directly under the RAM, but they're separated by two power planes, and the board boots correctly under JTAG control. It's when the JTAG is inactive that the problem occurs. – pingswept Nov 17 '10 at 4:02
• you are pulling the jtag tclk and trst to safe states ? – Tim Williscroft Nov 17 '10 at 4:30
• Yes, all the JTAG inputs are pulled up to 3.3 V, so their state shouldn't change unless JTAG is attached and driving them. – pingswept Nov 17 '10 at 14:54