AT91SAM9G20 - ResetController Problem [Errata 44.3.5.1]

ManuelSahm · **Joined:** Tue Jun 26, 2007 6:27 pm **Posts:** 82

Hello I have the following problem with the at91sam9g20 and a software + hardware reset:

44.3.5 Reset Controller (RSTC)
44.3.5.1 RSTC: Reset During SDRAM Accesses
When a User Reset occurs during SDRAM read access, the SDRAM clock is turned off while
data are ready to be read on the data bus. The SDRAM maintains the data until the clock
restarts.
If the user Reset is programmed to assert a general reset, the data maintained by the SDRAM
leads to a data bus conflict and adversely affects the boot memories connected on the EBI:
â€¢ NAND Flash boot functionality, if the system boots out of internal ROM.
â€¢ NOR Flash boot, if the system boots on an external memory connected on the EBI CS0.
Problem Fix/Workaround
1. Avoid User Reset to generate a system reset.
2. Trap the User Reset with an interrupt.
In the interrupt routine, Power Down SDRAM properly and perform Peripheral and Processor
Reset with software in assembler.

I tried the following code in the kernel-file /arch/arm/mach-at91/at91sam9260.c

Code:

#include <mach/at91sam9_sdramc.h>
static void soft_user_reset (void)
{
   //;disable IRQs
        asm("MRS r0, CPSR");
        asm("ORR r0, r0, #0x80");
        asm("MSR CPSR_c, r0");

   //change refresh rate to block all data accesses
   //asm("LDR r0, =0xFFFFEA04");// AT91_SDRAMC_TR = 0xFFFFEA04
   //asm("LDR r1, =1");
   //asm("STR r1, [r0]");
   at91_sys_write(AT91_SDRAMC_TR,1);

   //prepare power down command
   //asm("LDR r0, =0xFFFFEA10");//AT91_SDRAMC_LPR = 0xFFFFEA10
   //asm("LDR r1, =2");

   //prepare proc_reset and periph_reset
   //asm("LDR r2, =0xFFFFFD00");//AT91_RSTC_RCR = 0xFFFFFD00
   //asm("LDR r3, =0xA5000005");

   //perform power down command
   //asm("STR r1, [r0]");
   at91_sys_write(AT91_SDRAMC_LPR,AT91_SDRAMC_LPCB_POWER_DOWN); // oder AT91_SDRAMC_LPCB_DEEP_POWER_DOWN

   //perform proc_reset and periph_reset (in the ARM pipeline)
   //asm("STR r3, [r2]");
   at91_sys_write(AT91_RSTC_CR, AT91_RSTC_KEY | AT91_RSTC_PROCRST | AT91_RSTC_PERRST);
}

static void at91sam9260_reset(void)
{
   //at91_sys_write(AT91_RSTC_CR, AT91_RSTC_KEY | AT91_RSTC_PROCRST | AT91_RSTC_PERRST);
   soft_user_reset();
}

like it is mentioned in the datasheets as a workaround.

1.) after a "kill 1" command in linux the system sometimes hangs on reboot at printing "Romstart"
2.) If i press the hardware reset button the system sometimes hangs on reboot at printing "Romstart"

Only a power off -> power on could force the board to reboot again.

What could I do - why doesnÂ´t the workaround work ?

Thanks
Manuel Sahm

Noel_V · **Posted:** Wed Oct 14, 2009 8:25 am

Hello,

Any updates on this matter ?

I'm struggling with the SAME problem.

From time to time the AT91SAM9G20 hangs in "ROMBOOT" (after a watchdog reset) .. the only way to get it running if this happens is UNPOWER/RE-POWER the board. { I' m booting form NAND }

I have been writing some test code to 'trigger' this 'error' effect, but is seems not so evident get in this state, in other words sometimes it hangs sometimes it does not hang.
Ive been trying this in order to make sure that the work-around (as described into that errata) is working.

Regards Noel.

pciarfella · **Joined:** Tue Oct 27, 2009 11:36 pm **Posts:** 1

Hello,

We are also having this problem.

Have either of you solved it? If so, how?

Regards and thank you,

Paul C

sazproliphix · **Joined:** Sun Mar 08, 2009 6:31 am **Posts:** 13

Hi,
I think the issue might be that when you execute the reset procedure, described in the errata, you need to be running out of cache and not from SDRAM, which you need to disable before you hit the reset controller.
Steve

sazproliphix · **Joined:** Sun Mar 08, 2009 6:31 am **Posts:** 13

ManuelSahm wrote:

Hello I have the following problem with the at91sam9g20 and a software + hardware reset:

44.3.5 Reset Controller (RSTC)
44.3.5.1 RSTC: Reset During SDRAM Accesses
When a User Reset occurs during SDRAM read access, the SDRAM clock is turned off while
data are ready to be read on the data bus. The SDRAM maintains the data until the clock
restarts.
If the user Reset is programmed to assert a general reset, the data maintained by the SDRAM
leads to a data bus conflict and adversely affects the boot memories connected on the EBI:
â€¢ NAND Flash boot functionality, if the system boots out of internal ROM.
â€¢ NOR Flash boot, if the system boots on an external memory connected on the EBI CS0.
Problem Fix/Workaround
1. Avoid User Reset to generate a system reset.
2. Trap the User Reset with an interrupt.
In the interrupt routine, Power Down SDRAM properly and perform Peripheral and Processor
Reset with software in assembler.

I tried the following code in the kernel-file /arch/arm/mach-at91/at91sam9260.c

Code:

#include <mach/at91sam9_sdramc.h>
static void soft_user_reset (void)
{
   //;disable IRQs
        asm("MRS r0, CPSR");
        asm("ORR r0, r0, #0x80");
        asm("MSR CPSR_c, r0");

   //change refresh rate to block all data accesses
   //asm("LDR r0, =0xFFFFEA04");// AT91_SDRAMC_TR = 0xFFFFEA04
   //asm("LDR r1, =1");
   //asm("STR r1, [r0]");
   at91_sys_write(AT91_SDRAMC_TR,1);

   //prepare power down command
   //asm("LDR r0, =0xFFFFEA10");//AT91_SDRAMC_LPR = 0xFFFFEA10
   //asm("LDR r1, =2");

   //prepare proc_reset and periph_reset
   //asm("LDR r2, =0xFFFFFD00");//AT91_RSTC_RCR = 0xFFFFFD00
   //asm("LDR r3, =0xA5000005");

   //perform power down command
   //asm("STR r1, [r0]");
   at91_sys_write(AT91_SDRAMC_LPR,AT91_SDRAMC_LPCB_POWER_DOWN); // oder AT91_SDRAMC_LPCB_DEEP_POWER_DOWN

   //perform proc_reset and periph_reset (in the ARM pipeline)
   //asm("STR r3, [r2]");
   at91_sys_write(AT91_RSTC_CR, AT91_RSTC_KEY | AT91_RSTC_PROCRST | AT91_RSTC_PERRST);
}

static void at91sam9260_reset(void)
{
   //at91_sys_write(AT91_RSTC_CR, AT91_RSTC_KEY | AT91_RSTC_PROCRST | AT91_RSTC_PERRST);
   soft_user_reset();
}

like it is mentioned in the datasheets as a workaround.

1.) after a "kill 1" command in linux the system sometimes hangs on reboot at printing "Romstart"
2.) If i press the hardware reset button the system sometimes hangs on reboot at printing "Romstart"

Only a power off -> power on could force the board to reboot again.

What could I do - why doesnÂ´t the workaround work ?

Thanks
Manuel Sahm

I don't see this code in the version I have. What Linux version do you have? Where do you stand on resolving this issue? I'm working on the assumption that you need to disable all IRQs and make sure the code is all in cache and not in sdram.
thanks,
Steve

sazproliphix · **Joined:** Sun Mar 08, 2009 6:31 am **Posts:** 13

Hi all,
Just a brief update on this issue. We have confirmed with Atmel's engineers that they DO NOT have a proven fix for this problem that will run reliably under Linux. They thought they did, but when we encouraged them to run it many times, their "fix" failed.

The errata's "fix" also does not work reliably even when ported to Linux.

In the meantime, we have a significantly more reliable solution and are continuing to test it to make sure its rock solid before claiming we have a fix.

The bottom line is serious progress has been made on a software work around to resolve this processor reset design issue.

Steve

NOEL_AT91 · **Joined:** Mon Oct 19, 2009 3:53 pm **Posts:** 4

Any UPDATES?

Someone who was able to solve/ work-around this?

Thankx , Noel.

sazproliphix · **Joined:** Sun Mar 08, 2009 6:31 am **Posts:** 13

NOEL_AT91 wrote:

Any UPDATES?

Someone who was able to solve/ work-around this?

Thankx , Noel.

Yes we have. However, Atmel has yet to acknowledge our fix. They claim to be busy on higher priority issues and lack the resources to address this or fix the data sheet. Our fix works for us and has not been an issue now for over a month. Atmel's work-around in the data sheet does not work under Linux. I can post the details of what we did if you like.
Steve

ManuelSahm · **Joined:** Tue Jun 26, 2007 6:27 pm **Posts:** 82

Quote:

I can post the details of what we did if you like.
Steve

That would be great.

Thanks

sazproliphix · **Joined:** Sun Mar 08, 2009 6:31 am **Posts:** 13

ManuelSahm wrote:

Quote:

I can post the details of what we did if you like.
Steve

That would be great.

Thanks

In file: /arch/arm/kernel/process.c in function arm_machine_restart, comment out these two calls:

cpu_proc_fin();
setup_mm_for_reboot(mode);

In the above function I commented out two function calls. These functions flush and disable the caches and resets the MMU. In order to guarantee that our code is running from icache, we don't want the icache disabled. There could be alternatives to what I did, but this seems to work.

The next file I changed was /arch/arm/mach-at91/at91sam9rl.c.
The function I changed is at91sam9rl_reset(). It is very different
that the original Linux version.

static void at91sam9rl_reset(void) {
unsigned int mask;
mask = (unsigned int)0xFFFFFFFF;

/* enable user reset bits in reset controller */
at91_sys_write(AT91_RSTC_MR, ((0xA5<<24) | (0x04<<8) |
AT91_RSTC_URSTIEN | AT91_RSTC_URSTEN));

/* Disable all IRQs */
at91_sys_write(AT91_AIC_IDCR, mask);

/* Disable LCDC DMACON set DMAEN to 0 */
__raw_writel(0, (GlobalLcdcMmio + ATMEL_LCDC_DMACON));
/* GlobalLcdcMmio is a global I set within atmel_lcdfb.c so that I
know the address of the LCDCD_DMACON register in this context */

/* Disable debug UART */
at91_sys_write((AT91_DBGU+ATMEL_PDC_PTCR),
(ATMEL_PDC_RXTDIS + ATMEL_PDC_TXTDIS));

power_down_reset();
}

The power_down_reset() function is in assembler. I can't get to it now since our serever is down. As I recall, it was pretty complicated code I wrote to make sure its executes in cache and doesn't go out to SDRAM while resetting. I'll post that in a day or so.

Good luck.
Steve

colonel-panic · **Joined:** Wed Dec 09, 2009 4:06 pm **Posts:** 2

I've just posted a patch for this to linux-arm-kernel. Seems to work for me ...

http://lists.infradead.org/pipermail/linux-arm-kernel/2009-December/005795.html

sazproliphix · **Joined:** Sun Mar 08, 2009 6:31 am **Posts:** 13

colonel-panic wrote:

I've just posted a patch for this to linux-arm-kernel. Seems to work for me ...

http://lists.infradead.org/pipermail/linux-arm-kernel/2009-December/005795.html

We have a different processor, AT91SAM9RL, but I think this fix would work for ours as well. It does basically what I implemented, which also works. I tested it and wrote code to force a reboot and it successfully rebooted 1000 times.

Atmel should add this, or similar, to their datasheet since the current documented work-around isn't correct.

Steve

NOEL_AT91 · **Joined:** Mon Oct 19, 2009 3:53 pm **Posts:** 4

Hi, ALL

At the current time I'm implementing the above patch, and I assume that the USER reset will work now.

BUT:

I had similar issue's with the WATCHDOG reset , and I think the 'same' implementation will be needed for WATCHDOG reset.

{meaning that a WATCHDOG reset, can NOT RESET the AT91G20 directly !}

Regards, Noel

sazproliphix · **Joined:** Sun Mar 08, 2009 6:31 am **Posts:** 13

NOEL_AT91 wrote:

Hi, ALL

At the current time I'm implementing the above patch, and I assume that the USER reset will work now.

BUT:

I had similar issue's with the WATCHDOG reset , and I think the 'same' implementation will be needed for WATCHDOG reset.

{meaning that a WATCHDOG reset, can NOT RESET the AT91G20 directly !}

Regards, Noel

That is correct. I needed to implement a similar change to the watchdog code. I needed to prevent the watchdog from directly resetting the processor. But instead capture the watchdog reset and then call the same function as was called in the non-watchdog case.

Steve

colonel-panic · **Joined:** Wed Dec 09, 2009 4:06 pm **Posts:** 2

The watchdog is meant to give some fail safe method of recovery, it's not going to be fail safe if it has to be implemented using an interrupt handler. You may as well use a software watchdog.

This will probably prevent some hardware passing EMC immunity testing

.

AT91SAM9G20 - ResetController Problem [Errata 44.3.5.1]

Who is online