AT91SAM9G45 stays locked with NRST-Pin permanently down

[MatthiasKunze]

Hello, I have a problem with a couple of devices coming back from customers. The Reset Controller from the G45 kept the signal NRST permanently to "0". Normally even with a faulty configuration of the Reset Controller the processor can not keep this signal to "0" longer than 2 seconds. I did not find anything in the Chip Errata concerning the Reset Controller.
In order to reactivate the device I needed to cut the VDDBU which resets the Reset Controller. The G45 released the NRST pin after this and the device functioned normally.
Somebody had a similar problem? Do you know any configuration possible or a known problem which can bring the Reset Controller in this state (NRST drives 0 permanently)?
The 32kHz crystal keeps running. Maybe the On Chip RC OSC is stopped and the RSTC has not longer a clock source?
I couold even not connect a debugger.....;
I have still 1 device locked on my desk.........
Any ideas are welcome,
Thanks,

Mat

[majo]

Hello Matthias,

I have the same problem. Did you solve the problem in meantime?

Any ideas are also welcome,
Thanks,
majo

[falingtrea]

One possiblility is that you have the watchdog reset enabled and set to drive the external reset, have the watchdog timer set to less than 2 seconds, and the external reset set to max (2 seconds). In this situation, the watchdog timer will fire before the external reset is complete and the external reset would then never clear.

[majo]

I think that is not the case on our device. We have the external reset length set to minimum (60us) and the watchdog timer is set to maximum (0xFFF - 15.996s).

Any other ideas?
Thanks in advance.

[falingtrea]

Looking at the Reset Controller, it looks like it is run on slow clock. If you are using an external 32kHz crystal, maybe when you switch from the RC Oscillator to the external 32 kHz it is not being done per the data sheet sequencing. The Clock generator and power management sections use VDDBU to preserve settings, so pulling VDDBU would default them also.

[CptTitanic]

As Tim has indicated the SAM9xxx parts have historically been very sensitive to power supply sequencing, especially with 3 or 4 different voltages to provide. Board designs need to take this into consideration, and it can be a particularly difficult with short on-off-on power cycles. Atmel has board designs and app notes covering some of this.

Look at the rise times on your various supplies on a scope.

NRST is a bidirectional pin and can be driven externally, or internally, by an open-drain driver. The SCLK is designed to enforce a reset until the clock stabilizes, and there is often a power-on-reset thresholding device.

Consider if you have external devices, or JTAG pods, driving the pin low. Devices which drive the pin high (as opposed to using the pull up) can also be problematic.

[SandrineHL]

Hi All,

I have exactly the same issue with our AT91SAM9G45 board.
Have you solved this issue ?
Any information about this point would be really appreciated !!!

Many thanks in advance,
Sandrine.

[majo]

Hi SandrineHL,

we did not really solve this issue. But in the last time this issue is very, very rare.
In the first design we had, we have left the WKUP pin floating by accident. Think this increased the problem. Not sure if the issue is solved with this changed.
An engineer form Atmel told us that it might not be the correct use of the processor if we use the internal RTC in conjunction with a power mains switch. He stated that he things that the internal RTC is intended to be used with the shutdown feature of the processor. Not sure about this.
We started a request at the Atmel customer support but didn't get any answer until now.

Cheers,
majo

[CptTitanic]

Is it the same issue, or one with a similar symptom? Insufficient detail on board, and how it differs to reference designs.

Does your board run the internal RTC from a battery?

Have you eliminated power supply sequencing as a cause?

Does the problem occur when you initially power up the board?

After you reset it? Repeatedly, intermittently?

[majo]

Hi CptTitanic,

in that schematic part our design differs from the reference design. And yes, we run the internal RTC from a battery. But the reference board had sometimes the same issue (2 times I think). Ok, I don't remember whether it has been with the AT91sam9G45-EK or with the AT91SAM9263-EK board anymore since we used both.

It is very hard to prove any solution because it is that rare. Currently we are running tests under the following conditions: 30s power on 5s power off for over a month now with 2 devices. No problems so far. But I still have a locked device on my desk.

We had a look at the power sequencing also and also asked the Atmel support for that. They meant that it might be that the core voltage may have a bit a slow slew rate. We corrected this but as I already said it's hard to say if it is solved since the issue is rare.

What I can say is that we saw the issue definitively when power up the device. Think we hadn't had the problem after a reset (reset button), but we normally don't do that.

When the device is locked nothing helps but cutting VddBu!

[DoktorFurunkel]

Same here. We are going into serial production in a few weeks
I think power cycling isn't the problem here.
I accidently flashed a faulty firmware, so after the bootloader stage, our maching gets reseted internal watchdog. This is an endless loop. After 10-30h i have the NRST-down problem. One boot cycle needs 30seconds. So the problem occurs every 1200 up to 3600 Watchdog resets.

Now i'm going to make a setup which automatically power cycles our machine to find out if this problem is "Watchdog only".

You Guys have recent news on this topic ?

Greeetings

[SandrineHL]

Hi Everybody,

Here, I continue to test this issue with an automatic test bench with one start-up every 10 seconds on 4 boards.
And this way I can catch the crash quite easily.

I made several changes to my boot code and my conclusions at the moment are:
- the processor is stopped when it tries to switch from the internal RC to the external slow clock (32 kHz)
- when it is stopped, the 32kHz doesn't oscillate... That's why the boot sequence is stopped
- THE ONLY WAY to have the board booting again is to reset the backup unit by removing the VDDBU (on our design it is a cell battery) and resetting the board -> after that the 32 kHz oscillate again and the board boots-up correctly with the cell battery connected

The modifications I have made to my boot code concern the timings when booting from the internal RC to the external slow clock (as described in the Atmel datasheet).
But I have always the problem... So now I will try to increase significantly those timings just for test...

Good Luck !
Sandrine.

[DoktorFurunkel]

- when it is stopped, the 32kHz doesn't oscillate... That's why the boot sequence is stopped

Interesting

Good Luck !
Sandrine.

Thx... you too...

[drana]

Hello,
We have seen the same problem.
We can replicate if we apply 1 sec power on, 1 sec off. 

Has anybody found a solution or is an internal Atmel bug?

I would not encourage anyone to go into production with this.

Dragos

[majo]

Hello,

since we didn't find a solution (Atmel has been informed - they had also no solution). We don't use that functionality anymore. We don't backup Vddbu with a battery anymore. We use an external RTC.

majo