Sign in

username:

password:



Not a member?

Search AT91SAM



Search tips

Subscribe to AT91SAM



Sponsor

controlSUITE™ software
Comprehensive.
Intuitive.
Optimized.
Real-world software for real-time control. Details Here!

Ads

Discussion Groups

See Also

DSPFPGAElectronics

Discussion Groups | AT91SAM ARM | Reset Behavior

For users of the Atmel AT91SAM7 and AT91SAM9 ARM CPU chips. Atmel has taken a new direction by combining on chip flash and ram with the ARM CPU on a single die. This provides low cost devices for small systems using the ARM CPU. This group is to exchange information to help users get started and learn how to use the devices.

Reset Behavior - Nick Howes - Jan 26 10:26:06 2009

I'm trying to figure out the reset behavior of my AT91SAM7XC256 :

One of the features of our product is that the firmware can be
upgraded. We have a firmware programmer routine that runs out of RAM
and programs the flash from data received over a comms link. It all
works fine if we cycle power at the end. But, if we try to reset the
device programmatically, via:
AT91C_BASE_RSTC->RSTC_RCR = ((0xA5 << 24) | AT91C_RSTC_PROCRST |
AT91C_RSTC_PERRST );
it usually goes off in the weeds.

We use the same reset technique in other code in the product and it
always works fine. It only seems to fail after new code has been
written to the flash.

I suspected a remap problem (we do remap the vectors to RAM), but
AT91C_RSTC_PERRST is supposed to clear remap (and other tests seem to
eliminate it as the culprit).

I've wasted a lot of time trying to figure this out and I've gotten
nowhere. Does anyone have any insight as to what might be happening?

thanks, Nick

------------------------------------

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!


(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )


Re: Reset Behavior - 42Bastian - Jan 26 10:51:18 2009

Nick Howes schrieb:

> We use the same reset technique in other code in the product and it
> always works fine. It only seems to fail after new code has been
> written to the flash.

Maybe the Flash isn't reset and still in programming mode ?

--
42Bastian

Note: SPAM-only account, direct mail to bs42@...

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Reset Behavior - Nick Howes - Jan 26 12:04:05 2009

"42Bastian" d...@sciopta.com wrote:
> Maybe the Flash isn't reset and still in programming mode ?

That sounds hopeful, but as far as I know, for the AT91SAM7X, once
the programming is complete and FRDY in MC_FSR goes high, the flash
is ready for use. Maybe I'm missing something?

thanks, Nick

------------------------------------

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!


(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Reset Behavior - Nick Howes - Jan 26 12:23:05 2009

I should have also said that if I load the same code as is already in
the device, it resets OK. Also, if the code only has minor changes,
it also usually resets OK. Both of these made me suspect a reset
vector problem, but I can't see how.

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Re: Reset Behavior - 42Bastian - Jan 26 13:28:00 2009

Nick Howes schrieb:
> I should have also said that if I load the same code as is already in
> the device, it resets OK. Also, if the code only has minor changes,
> it also usually resets OK. Both of these made me suspect a reset
> vector problem, but I can't see how.

I not sure if your chip allows un-doing remap, if so: Did you try
undoing it before reset ?

BTW: Why not just start the new code w/o reset ?
--
42Bastian

Note: SPAM-only account, direct mail to bs42@...

------------------------------------

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!


(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Reset Behavior - Nick Howes - Jan 26 13:47:53 2009

"42Bastian" d...@sciopta.com wrote:

> I not sure if your chip allows un-doing remap, if so: Did you try
> undoing it before reset ?

The documentation says:
"Writing PERRST at 1 resets all the embedded peripherals,
including the memory system, and, in particular, the Remap Command."

The documentation also says that remap can be toggled via:
AT91C_BASE_MC->MC_RCR = AT91C_MC_RCB;
I tried that to no avail.
> BTW: Why not just start the new code w/o reset ?
Mainly because I want to ensure that I'm starting in a known state.
But maybe I should try it and see what happens.
At this point, I also want to understand what the chip is actually
doing.
thanks, Nick
------------------------------------

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!


(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

AT91SAM group member - some info required - Maziar Tasbihi - Jan 26 14:06:10 2009

Hello 42Bastian,
I saw that you were making posts on the AT91SAM group, and I had a look at your company. Please can you explain in few sentences what is your company best at, and what are the main products. It looks to be a big company. For example, do you also make the hardware products, or only software? What are the software main points? Also, if you do not make hardware, then do you recommend the hardware for the job to run your software? Where are the your products used often and what are the stand out points?
Thank you and with regards,
Maziar Tasbihi

--- On Mon, 1/26/09, 42Bastian wrote:
From: 42Bastian
Subject: Re: [AT91SAM] Re: Reset Behavior
To: A...@yahoogroups.com
Date: Monday, January 26, 2009, 10:27 AM

Nick Howes schrieb:

> I should have also said that if I load the same code as is already in

> the device, it resets OK. Also, if the code only has minor changes,

> it also usually resets OK. Both of these made me suspect a reset

> vector problem, but I can't see how.

I not sure if your chip allows un-doing remap, if so: Did you try

undoing it before reset ?

BTW: Why not just start the new code w/o reset ?

--

42Bastian

Note: SPAM-only account, direct mail to bs42@...



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Reset Behavior - jellybean10025 - Jan 26 15:35:31 2009

This code works every time for me:

/////////////////////////////////////////////////////////////////
// Flash has been written now, so no calls except to RAM resident
/////////////////////////////////////////////////////////////////

pRSTC->RSTC_RCR = 0xA5000000 | C_RSTC_PROCRST | C_RSTC_PERRST |
C_RSTC_EXTRST;
while ((pRSTC->RSTC_RSR) & C_RSTC_SRCMP)
continue;

--- In A...@yahoogroups.com, Nick Howes wrote:
>
> I should have also said that if I load the same code as is already in
> the device, it resets OK. Also, if the code only has minor changes,
> it also usually resets OK. Both of these made me suspect a reset
> vector problem, but I can't see how.
>

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Reset Behavior - Nick Howes - Jan 26 15:59:39 2009

--- In A...@yahoogroups.com, "jellybean10025" wrote:

> while ((pRSTC->RSTC_RSR) & C_RSTC_SRCMP)

Well yeah, that makes perfect sense - I need to wait for the reset process to complete so that
it doesn't use the wrong vectors. It's quite obvious now that I know the answer!

Thank you very much!

- Nick
------------------------------------

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!


(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Reset Behavior - Nick Howes - Jan 26 16:17:52 2009

--- In A...@yahoogroups.com, "Nick Howes" wrote:
>
> --- In A...@yahoogroups.com, "jellybean10025" wrote:
>
> > while ((pRSTC->RSTC_RSR) & C_RSTC_SRCMP)
>
> Well yeah, that makes perfect sense - I need to wait for the reset process to
> complete so that it doesn't use the wrong vectors.

Well it seemed like this was the answer, but it hasn't solved my problem. :(

- Nick
------------------------------------

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!


(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Re: Reset Behavior - Yusuf Caglar AKYUZ - Jan 26 16:22:56 2009

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nick Howes wrote:
> --- In A...@yahoogroups.com, "Nick Howes" wrote:
>> --- In A...@yahoogroups.com, "jellybean10025" wrote:
>>
>>> while ((pRSTC->RSTC_RSR) & C_RSTC_SRCMP)
>> Well yeah, that makes perfect sense - I need to wait for the reset process to
>> complete so that it doesn't use the wrong vectors.
>
> Well it seemed like this was the answer, but it hasn't solved my problem. :(
>

I never thought your problem was so trivial so I never asked but are you enabling
user reset before resetting? I know your reset is working normally but just in case...

Caglar

> - Nick

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkl+KkYACgkQ/nL+S5dojegK+ACgp9FEoPyPA3RXZvUWA+OCG7j1
acMAoJgnYy1bG1qcECTNirPkY4CQJJSB
=9CAs
-----END PGP SIGNATURE-----

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Reset Behavior - Nick Howes - Jan 26 17:25:21 2009

--- In A...@yahoogroups.com, Yusuf Caglar AKYUZ wrote:
>
> I never thought your problem was so trivial so I never asked but are you enabling
> user reset before resetting? I know your reset is working normally but just in case...

Hi Caglar,

User reset is not enabled.

More info:
This bit of code works:
AT91C_BASE_RSTC->RSTC_RCR = ((0xA5 << 24) | AT91C_RSTC_PERRST |
AT91C_RSTC_EXTRST); //reset the peripherals and remap
while ((AT91C_BASE_RSTC->RSTC_RSR) & AT91C_RSTC_SRCMP); //wait for reset to
complete
((void(*)(void))0x00100000)(); //transfer control to reset vector in Flash (0x00100000)

but if I use the following, it fails:
AT91C_BASE_RSTC->RSTC_RCR = ((0xA5 << 24) | AT91C_RSTC_PERRST |
AT91C_RSTC_EXTRST); //reset the peripherals and remap
while ((AT91C_BASE_RSTC->RSTC_RSR) & AT91C_RSTC_SRCMP); //wait for reset to
complete
AT91C_BASE_RSTC->RSTC_RCR = ((0xA5 << 24) | AT91C_RSTC_PROCRST);

I guess I can use the code that works, but I would dearly love to understand what is
happening.

- Nick
------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Re: Reset Behavior - Yusuf Caglar AKYUZ - Jan 26 18:02:39 2009

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nick Howes wrote:
> More info:
> This bit of code works:
> AT91C_BASE_RSTC->RSTC_RCR = ((0xA5 << 24) | AT91C_RSTC_PERRST |
> AT91C_RSTC_EXTRST); //reset the peripherals and remap
> while ((AT91C_BASE_RSTC->RSTC_RSR) & AT91C_RSTC_SRCMP); //wait for reset to
> complete
> ((void(*)(void))0x00100000)(); //transfer control to reset vector in Flash (0x00100000)
>
> but if I use the following, it fails:

can you try this one:

> AT91C_BASE_RSTC->RSTC_RCR = ((0xA5 << 24) | AT91C_RSTC_PERRST |
> AT91C_RSTC_EXTRST); //reset the peripherals and remap
> while ((AT91C_BASE_RSTC->RSTC_RSR) & AT91C_RSTC_SRCMP); //wait for reset to
> complete
> AT91C_BASE_RSTC->RSTC_RCR = ((0xA5 << 24) | AT91C_RSTC_PROCRST);
>

as:

AT91C_BASE_RSTC->RSTC_RCR = ((0xA5 << 24)
| AT91C_RSTC_PERRST
| AT91C_RSTC_EXTRST
| AT91C_RSTC_PROCRST);
while ((AT91C_BASE_RSTC->RSTC_RSR) & AT91C_RSTC_SRCMP);

> I guess I can use the code that works, but I would dearly love to understand what is
> happening.
>
> - Nick

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkl+QaEACgkQ/nL+S5dojeiglwCeJW380eVq4keynYLPbNVbHhTH
epwAnRuReaEbwYTslEG+0bRVaLab1vTL
=DYC8
-----END PGP SIGNATURE-----

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Reset Behavior - Nick Howes - Jan 26 18:24:31 2009

--- In A...@yahoogroups.com, Yusuf Caglar AKYUZ wrote:

> can you try:
>
> AT91C_BASE_RSTC->RSTC_RCR = ((0xA5 << 24)
> | AT91C_RSTC_PERRST
> | AT91C_RSTC_EXTRST
> | AT91C_RSTC_PROCRST);
> while ((AT91C_BASE_RSTC->RSTC_RSR) & AT91C_RSTC_SRCMP);

Yes, I've tried that and it doesn't work. And I've tried various similar sequences - e.g.
separating the PERRST from the PROCRST, going into an endless loop after the PROCRST, etc.

- Nick
------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Re: Reset Behavior - louie ouano - Jan 26 23:58:51 2009


>From the working and non working code, looks like the
difference is only the line that involves the PROCRST
define. Sounds like PROCRST is a processor reset and
might clear the program counter(I'm not sure on this).
If it does clear the PC, then the code execution would
basically go back to the start of your program causing
an infinite loop...

--- Nick Howes wrote:

> --- In A...@yahoogroups.com, Yusuf Caglar AKYUZ
> wrote:
>
> > can you try:
> >
> > AT91C_BASE_RSTC->RSTC_RCR = ((0xA5 << 24)
> > | AT91C_RSTC_PERRST
> > | AT91C_RSTC_EXTRST
> > | AT91C_RSTC_PROCRST);
> > while ((AT91C_BASE_RSTC->RSTC_RSR) &
> AT91C_RSTC_SRCMP);
>
> Yes, I've tried that and it doesn't work. And I've
> tried various similar sequences - e.g.
> separating the PERRST from the PROCRST, going into
> an endless loop after the PROCRST, etc.
>
> - Nick

------------------------------------

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!


(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Re: Reset Behavior - Eric Pasquier - Jan 27 2:58:36 2009

Can you please post your LowLevelInit sequence ?

Eric.
----- Original Message -----
From: Nick Howes
To: A...@yahoogroups.com
Sent: Tuesday, January 27, 2009 12:24 AM
Subject: [AT91SAM] Re: Reset Behavior
--- In A...@yahoogroups.com, Yusuf Caglar AKYUZ wrote:

> can you try:
>
> AT91C_BASE_RSTC->RSTC_RCR = ((0xA5 << 24)
> | AT91C_RSTC_PERRST
> | AT91C_RSTC_EXTRST
> | AT91C_RSTC_PROCRST);
> while ((AT91C_BASE_RSTC->RSTC_RSR) & AT91C_RSTC_SRCMP);

Yes, I've tried that and it doesn't work. And I've tried various similar sequences - e.g.
separating the PERRST from the PROCRST, going into an endless loop after the PROCRST, etc.

- Nick

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!


(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Reset Behavior - Nick Howes - Jan 27 8:15:31 2009

--- In A...@yahoogroups.com, "Eric Pasquier" wrote:

> Can you please post your LowLevelInit sequence ?

Hi Eric,

Is this is what you are asking for?=20

#define FMCN_PLL_1_0_US 48 //48 cycles for 1us
#define FMCN_PLL_1_5_US 72 //72 cycles for 1.5us
#define MOR_OSC_CNT 8 //1.52 - 2.9 ms depending on SLCK accuracy
#define PLLR_DIV 5 //18.432MHz =F7 5 =3D 3.6864MHz
#define PLLR_MUL 25 //3.6864MHz * 26 =3D 95.8464MHz
#define PLLR_PLL_CNT 28 //this value comes from the Atmel sample file=20
(number of slow clocks before LOCK bit set)
#define PLLR_USB 1 //1 means divide-by-two; 95.8464MHz =F7 2 =3D=20
47.9232MHz (48MHz - 0.16%)

void base_init() {

AT91C_BASE_MC->MC_FMR =3D (FMCN_PLL_1_5_US << 16) | AT91C_MC_FWS_1FWS;=20
//setup flash
=09
AT91C_BASE_PMC->PMC_MOR =3D (MOR_OSC_CNT << 8) | AT91C_CKGR_MOSCEN;=20
//enable Main Oscillator
while(!(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_MOSCS)); //wait for osc startup

AT91C_BASE_PMC->PMC_PLLR =3D (PLLR_USB << 28) | (PLLR_MUL << 16) |=20
(PLLR_PLL_CNT << 8) | PLLR_DIV; //setup PLL
while(!(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_LOCK)); //wait for PLL startup

AT91C_BASE_PMC->PMC_MCKR =3D AT91C_PMC_PRES_CLK_2; //set MCK divider to 2
while(!(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_MCKRDY)); //wait for clock to b=
e=20
ready
=09
AT91C_BASE_PMC->PMC_MCKR =3D AT91C_PMC_CSS_PLL_CLK |=20
AT91C_PMC_PRES_CLK_2; //set MCK source to PLL
while(!(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_MCKRDY)); //wait for clock to b=
e=20
ready
=09
}

(I tried waiting for AT91C_PMC_MCKRDY at the beginning of this routine, but=
it made no=20
difference.)
thx, Nick=20=20

------------------------------------

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!


(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Re: Reset Behavior - Eric Pasquier - Jan 27 10:48:18 2009

Can you please test this configuration :
- - - (ok)
pPMC->PMC_PLLR = ( - - - ) (ok)

// Wait the startup time (until PMC Status register LOCK bit is set)
while(!(pPMC->PMC_SR & AT91C_PMC_LOCK));

// Wait for the master clock if it was already initialized
while(!(pPMC->PMC_SR & AT91C_PMC_MCKRDY));

// Switch to slow clock + prescaler
pPMC->PMC_MCKR = AT91C_PMC_PRES_CLK_2;
while(!(pPMC->PMC_SR & AT91C_PMC_MCKRDY));

// Switch to fast clock + prescaler
pPMC->PMC_MCKR |= AT91C_PMC_CSS_PLL_CLK ;
while(!(pPMC->PMC_SR & AT91C_PMC_MCKRDY));

// Initialize AIC
AT91C_BASE_AIC->AIC_IDCR = 0xFFFFFFFF;
Eric
----- Original Message -----
From: Nick Howes
To: A...@yahoogroups.com
Sent: Tuesday, January 27, 2009 2:15 PM
Subject: [AT91SAM] Re: Reset Behavior
--- In A...@yahoogroups.com, "Eric Pasquier" wrote:

> Can you please post your LowLevelInit sequence ?

Hi Eric,

Is this is what you are asking for?

#define FMCN_PLL_1_0_US 48 //48 cycles for 1us
#define FMCN_PLL_1_5_US 72 //72 cycles for 1.5us
#define MOR_OSC_CNT 8 //1.52 - 2.9 ms depending on SLCK accuracy
#define PLLR_DIV 5 //18.432MHz ÷ 5 = 3.6864MHz
#define PLLR_MUL 25 //3.6864MHz * 26 = 95.8464MHz
#define PLLR_PLL_CNT 28 //this value comes from the Atmel sample file
(number of slow clocks before LOCK bit set)
#define PLLR_USB 1 //1 means divide-by-two; 95.8464MHz ÷ 2 =
47.9232MHz (48MHz - 0.16%)

void base_init() {

AT91C_BASE_MC->MC_FMR = (FMCN_PLL_1_5_US << 16) | AT91C_MC_FWS_1FWS;
//setup flash

AT91C_BASE_PMC->PMC_MOR = (MOR_OSC_CNT << 8) | AT91C_CKGR_MOSCEN;
//enable Main Oscillator
while(!(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_MOSCS)); //wait for osc startup

AT91C_BASE_PMC->PMC_PLLR = (PLLR_USB << 28) | (PLLR_MUL << 16) |
(PLLR_PLL_CNT << 8) | PLLR_DIV; //setup PLL
while(!(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_LOCK)); //wait for PLL startup

AT91C_BASE_PMC->PMC_MCKR = AT91C_PMC_PRES_CLK_2; //set MCK divider to 2
while(!(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_MCKRDY)); //wait for clock to be
ready

AT91C_BASE_PMC->PMC_MCKR = AT91C_PMC_CSS_PLL_CLK |
AT91C_PMC_PRES_CLK_2; //set MCK source to PLL
while(!(AT91C_BASE_PMC->PMC_SR & AT91C_PMC_MCKRDY)); //wait for clock to be
ready

}

(I tried waiting for AT91C_PMC_MCKRDY at the beginning of this routine, but it made no
difference.)

thx, Nick



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Reset Behavior - Nick Howes - Jan 27 11:36:23 2009

--- In A...@yahoogroups.com, "Eric Pasquier" wrote:

> Can you please test this configuration :

Hi Eric,

I tried the changes you suggested (including the AIC initialization stuff in your separate e-
mail) - it behaved in the same way.

- Nick
------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Reset Behavior - jellybean10025 - Jan 27 14:01:32 2009

Then I think you need to be looking elsewhere as Eric is suggesting.

The code I posted absolutely works. It is in thousands of our
production units and we do software updates frequently.

There must be something else going on here.

PS: We strip off the "AT91" to keep the typing down, but otherwise
don't touch the header files.

--- In A...@yahoogroups.com, "Nick Howes" wrote:
>
> --- In A...@yahoogroups.com, "Nick Howes" wrote:
> >
> > --- In A...@yahoogroups.com, "jellybean10025"
wrote:
> >
> > > while ((pRSTC->RSTC_RSR) & C_RSTC_SRCMP)
> >
> > Well yeah, that makes perfect sense - I need to wait for the reset
process to
> > complete so that it doesn't use the wrong vectors.
>
> Well it seemed like this was the answer, but it hasn't solved my
problem. :(
>
> - Nick
>

------------------------------------

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!


(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Reset Behavior - Nick Howes - Jan 27 15:21:37 2009

--- In A...@yahoogroups.com, "jellybean10025" wrote:
>
> Then I think you need to be looking elsewhere as Eric is suggesting.
>
> The code I posted absolutely works. It is in thousands of our
> production units and we do software updates frequently.
>
> There must be something else going on here.

Thanks for the info. You (and Eric) are probably right. I wish I could find it!

The workaround (jumping to the reset vector in flash) does seem to work reliably, so I guess
we could go with that.

Thanks to everyone for your suggestions!

- Nick
------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

RES: Re: Reset Behavior - Eric Pasquier - Jan 27 18:29:25 2009

I have been thinking about your problem for a couple of hours without
finding the reason.

But something is disturbing me.
According to the documentation, as soon as you assert

AT91C_BASE_RSTC->RSTC_RCR = ((0xA5 << 24)
| AT91C_RSTC_PERRST
| AT91C_RSTC_EXTRST
| AT91C_RSTC_PROCRST);

the ARM is in Reset state and you should not be able to execute

while ((AT91C_BASE_RSTC->RSTC_RSR) & AT91C_RSTC_SRCMP);

or even

((void(*)(void))0x00100000)(); //transfer control to reset vector in Flash
(0x00100000)

That's why I am thinking that your problem could be in the initialization
sequence, which should be at address 0x0000000 in flash ....

Eric.

-----Mensagem original-----
De: A...@yahoogroups.com [mailto:A...@yahoogroups.com] Em nome de Nick
Howes
Enviada em: mardi 27 janvier 2009 21:20
Para: A...@yahoogroups.com
Assunto: [AT91SAM] Re: Reset Behavior

--- In AT91SAM@yahoogroups .com,
"jellybean10025" wrote:
>
> Then I think you need to be looking elsewhere as Eric is suggesting.
>
> The code I posted absolutely works. It is in thousands of our
> production units and we do software updates frequently.
>
> There must be something else going on here.

Thanks for the info. You (and Eric) are probably right. I wish I could find
it!

The workaround (jumping to the reset vector in flash) does seem to work
reliably, so I guess
we could go with that.

Thanks to everyone for your suggestions!

- Nick

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!


(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

RES: Re: Reset Behavior - Nick Howes - Jan 27 19:07:21 2009

Hi Eric,

The "workaround" code is:

AT91C_BASE_RSTC->RSTC_RCR = (0xA5 << 24) | AT91C_RSTC_PERRST |
AT91C_RSTC_EXTRST; //reset the peripherals and remap
while ((AT91C_BASE_RSTC->RSTC_RSR) & AT91C_RSTC_SRCMP); //wait for reset to complete
((void(*)(void))0x00100000)(); //transfer control to reset vector in Flash

Note that I'm not trying to reset the processor, just the peripherals.

That said, I'm starting to think that this working is probably a fluke and that there must be
something not quite right in my crt0.s code and/or "LowLevelInit" code. I'm hoping to get a
block of time to look at it again tomorrow.

- Nick
------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

RES: Re: Reset Behavior - Nick Howes - Jan 28 19:54:25 2009

Well, I checked my startup code against the latest from Atmel (at91lib-1.4-at91sam7xc-ek).
There were a few minor differences, so I changed my code to match, and it made no
difference. At this point, I have to get on with other stuff - the workaround seems reliable
and that's what we're going with. I wish I understood what was happening.

------------------------------------

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!


(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Reset Behavior - Nick Howes - Mar 16 15:22:09 2009

--- In A...@yahoogroups.com, Nick Howes wrote:
>
> I'm trying to figure out the reset behavior of my AT91SAM7XC256 :

I'm embarrassed to say that (perhaps unsurprisingly) this turned out to be a bug in my code. Thanks for everyone's help and sorry for the waste of bandwidth.

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Re: Reset Behavior - Matt Andrew - Mar 18 2:45:40 2009

> I'm embarrassed to say that (perhaps unsurprisingly) this turned out to b=
e a bug in my code. =A0Thanks for everyone's help and sorry for the waste o=
f bandwidth.

Now that I've read this whole thread, I'm curious where the bug did
lie. And how did you find it? Just curious.
------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Re: Reset Behavior - Nick Howes - Mar 18 8:52:14 2009

> Now that I've read this whole thread, I'm curious where the bug did
> lie. And how did you find it? Just curious.

Hi Matt,

Part of my reset handler checks to see what type of reset occurred,
and part of this code examines certain RAM locations. Originally,
these RAM locations were defined as a separate memory in the ld
script. At some point, the ld script was rewritten and these RAM
locations became just another section in the RAM - this meant that
their absolute addresses could change from build to build. This led
to the wrong type of reset being detected, bad assumptions about the
memory state being made, and the code going off in the weeds.

Like most bugs, it seems embarrassingly simple - so obvious in
hindsight. I eventually found it just by thinking about the problem
after it had reared it's ugly head again - one of those eureka moments.
- Nick
------------------------------------

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!


(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )