Hi Fredrik,

I found the problem, I am using yagarto toolchain with exclipse.
My problem was that, Master clock set with 48Mhz and running clock with 18.432Mhz, by this way the configuration to write flash was wrong, when both Master clock and running clock was set with 48Mhz, the write to flash works ok.

I did not understand this, because if I tell cpu that runnning clock is 18.432Mhz and cristall is 18.432Mhz too, why writting to flash crash cpu.

regards

Paulo

----- Original Message -----
From: ffredrik
To: A...
Sent: Thursday, September 06, 2007 3:13 AM
Subject: Re: [AT91SAM] Re: Can't write to flash memory
Hi Paulo,

I still have the problem. It seems to appear occasionally, after certain
rebuilds. Can't figure out what causes it. What compiler do you use?

Fredrik
Paulo Silva wrote:

HI

I am having the same problem.

When I run the program via debug no problem codes works, but when I run it normaliy, cpu crashs when execute MC_FCR = MC_KEY | CMD;

Any sugestions about this, I am using Olimex SAM7-EX256 board.

Regards

Paulo

----- Original Message -----
From: shraddha chaudhari
To: A...
Sent: Thursday, July 19, 2007 11:57 AM
Subject: Re: [AT91SAM] Re: Can't write to flash memory
hi,

u should read this errata which i read in AT91SAM7S64 (PRelim_SAM7S64_big.pdf)

read the errata for Master Clock page 541
u have to set the

AT91C_BASE_MC->MC_FMR

register with apporpiate wait states while startup or else while flashing it generates exceptions

i am running the controller at 48 Mhz
and have the set the wait states as

AT91C_BASE_MC->MC_FMR = ((AT91C_MC_FMCN)&(48 <<16)) | AT91C_MC_FWS_1FWS ;

check if it works

Regards,
Shraddha

ffredrik wrote:
Hi Mark,

I wait for the write to finish, the way you do it.
The processor traps to "undefined instruction" when
I try to write MC_FCR

Fredrik

Mark Butcher wrote:
Hi

I can't explain the problem that you have from the details that I have
seen. You have written that the code is running out of RAM and
interrupts are blocked, which would be correct.

Are you waiting for the FLASH to signal that it has completed after
the write? Could you be leaving the region before it is ready
(although I don't think that this would be address dependent).

Eg.
MC_FCR = (FLASH_KEY | FCMD_WP | (ulPage<<8));
while (!(MC_FSR & FLASH_READY)) {}

Regards

Mark

www.uTasker.com

Yahoo! Groups Links

--
Unlimited freedom, unlimited storage. Get it now

hi,

u should read this errata which i read in AT91SAM7S64 (PRelim_SAM7S64_big.pdf)

read the errata for Master Clock page 541

u have to set the

AT91C_BASE_MC->MC_FMR

register with apporpiate wait states while startup or else while flashing it generates exceptions

i am running the controller at 48 Mhz
and have the set the wait states as

AT91C_BASE_MC->MC_FMR = ((AT91C_MC_FMCN)&(48 <<16)) | AT91C_MC_FWS_1FWS ;

check if it works

Regards,
Shraddha

ffredrik wrote:
Hi Mark,

I wait for the write to finish, the way you do it.
The processor traps to "undefined instruction" when
I try to write MC_FCR

Fredrik

Mark Butcher wrote: Hi

I can't explain the problem that you have from the details that I have
seen. You have written that the code is running out of RAM and
interrupts are blocked, which would be correct.

Are you waiting for the FLASH to signal that it has completed after
the write? Could you be leaving the region before it is ready
(although I don't think that this would be address dependent).

Eg.
MC_FCR = (FLASH_KEY | FCMD_WP | (ulPage<<8));
while (!(MC_FSR & FLASH_READY)) {}

Regards

Mark

www.uTasker.com

Yahoo! Groups Links

---------------------------------
Unlimited freedom, unlimited storage. Get it now

Fredrik

Are you debugging in assembler? It sounds more as though the program
running from RAM is corrupted in this case. I see no reason why the
processor should otherwise trap when writing to MC_FCR.

Try stepping though the code in assember (not in C code since you
proably won't see whether the assembler is corrupted or not) when it
works correctly and note the instructions used (and also the alignment
[thumb or arm mode] plus the processor mode [supervisor, user etc.]
and state of the interrupt mask bits in the processor status
register). Then repeat in the case which fails and possibly you will
see a difference - for example the operating mode or the intsructions
it is trying to execute.

Nasty problem you have unfortunately. I have been writing to the very
last sector in FLASH in the SAM7X256 very recently without any
difficulties so I don't expect some strange chip bug.

Regards

Mark

http://www.uTasker.com

--- In A..., ffredrik wrote:
>
> Hi Mark,
>
> I wait for the write to finish, the way you do it.
> The processor traps to "undefined instruction" when
> I try to write MC_FCR
>
> Fredrik
>
> Mark Butcher wrote: Hi
>
> I can't explain the problem that you have from the details that I have
> seen. You have written that the code is running out of RAM and
> interrupts are blocked, which would be correct.
>
> Are you waiting for the FLASH to signal that it has completed after
> the write? Could you be leaving the region before it is ready
> (although I don't think that this would be address dependent).
>
> Eg.
> MC_FCR = (FLASH_KEY | FCMD_WP | (ulPage<<8));
> while (!(MC_FSR & FLASH_READY)) {}
>
> Regards
>
> Mark
>
> www.uTasker.com
>
>
> Yahoo! Groups Links
>

Hi Mark,

I wait for the write to finish, the way you do it.
The processor traps to "undefined instruction" when
I try to write MC_FCR

Fredrik

Mark Butcher wrote: Hi

I can't explain the problem that you have from the details that I have
seen. You have written that the code is running out of RAM and
interrupts are blocked, which would be correct.

Are you waiting for the FLASH to signal that it has completed after
the write? Could you be leaving the region before it is ready
(although I don't think that this would be address dependent).

Eg.
MC_FCR = (FLASH_KEY | FCMD_WP | (ulPage<<8));
while (!(MC_FSR & FLASH_READY)) {}

Regards

Mark

www.uTasker.com

Yahoo! Groups Links

Hi

I can't explain the problem that you have from the details that I have
seen. You have written that the code is running out of RAM and
interrupts are blocked, which would be correct.

Are you waiting for the FLASH to signal that it has completed after
the write? Could you be leaving the region before it is ready
(although I don't think that this would be address dependent).

Eg.
MC_FCR = (FLASH_KEY | FCMD_WP | (ulPage<<8));
while (!(MC_FSR & FLASH_READY)) {}

Regards

Mark

www.uTasker.com

ffredrik wrote:
> Sorry, forget about writing below 0x40000 , I was wrong there.
> The routine resides in SRAM, and ints are disabled.
>

I think you mean 0x100000 :)

Then I don't know what else to say, maybe you are trapping in a
unaligned memory access, posting your code will give more info.

Kind Regards,
Caglar AKYUZ

Sorry, forget about writing below 0x40000 , I was wrong there.
The routine resides in SRAM, and ints are disabled.

Regards

Caglar Akyuz wrote: Caglar Akyuz wrote:
> ffredrik wrote:
>> The problem occurs with SAM7XC256 and SAM7S256.
>>
>> The flash memory is 0x40000 bytes [%6kB] and is mapped to 0x100000,
> i.e. the range = 0x100000 to 0x13FFFF.
>> I'm using SAM7X256 and writing to address 0x0013FF00 successfully. There
> are 1024 pages and you are writing pages below 512 successfully. Is it
> possible that you are making some mistake while calculating the page
> number in your code? Just in case...
>

Wo wo wooo! Please just ignore this. Sorry for the garbage.

You said in your first mail that:

"Writes below 0x100000 work fine, at this address and above, the
processor crashes"

How do you write below 0x100000 if your flash is mapped to 0x100000? I
think you are not writing anything to flash at all.

I guess you have something wrong with your flash write routines, may be
they are not reside in the RAM, maybe interrupts are not disabled or
something wrong with the addresses...

Regards
Caglar AKYUZ

Yahoo! Groups Links

Caglar Akyuz wrote:
> ffredrik wrote:
>> The problem occurs with SAM7XC256 and SAM7S256.
>>
>> The flash memory is 0x40000 bytes [%6kB] and is mapped to 0x100000,
> i.e. the range = 0x100000 to 0x13FFFF.
>> I'm using SAM7X256 and writing to address 0x0013FF00 successfully. There
> are 1024 pages and you are writing pages below 512 successfully. Is it
> possible that you are making some mistake while calculating the page
> number in your code? Just in case...
>

Wo wo wooo! Please just ignore this. Sorry for the garbage.

You said in your first mail that:

"Writes below 0x100000 work fine, at this address and above, the
processor crashes"

How do you write below 0x100000 if your flash is mapped to 0x100000? I
think you are not writing anything to flash at all.

I guess you have something wrong with your flash write routines, may be
they are not reside in the RAM, maybe interrupts are not disabled or
something wrong with the addresses...

Regards
Caglar AKYUZ

ffredrik wrote:
> The problem occurs with SAM7XC256 and SAM7S256.
>
> The flash memory is 0x40000 bytes [%6kB] and is mapped to 0x100000, i.e. the range = 0x100000 to 0x13FFFF.
>

I'm using SAM7X256 and writing to address 0x0013FF00 successfully. There
are 1024 pages and you are writing pages below 512 successfully. Is it
possible that you are making some mistake while calculating the page
number in your code? Just in case...

Regards
Caglar AKYUZ

The problem occurs with SAM7XC256 and SAM7S256.

The flash memory is 0x40000 bytes [%6kB] and is mapped to 0x100000, i.e. the range = 0x100000 to 0x13FFFF.

Note that I am not trying to overwrite any code. I am
actually trying to write into 0x13FF00, which is not
used.

Caglar Akyuz wrote: ffredrik wrote:
> Hi all,
>
> I have encountered a problem when storing user data in the program
> flash memory.
>
> I use the normal code:
>
> mc->MC_FCR = AT91C_MC_WRITE_KEY | AT91C_MC_FCMD_START_PROG | (page << 8);
>
> Writes below 0x100000 work fine, at this address and above, the
> processor crashes.
>
> The problem seems to occur with various SAM7 models I have tried.
>

Which SAM7 are you using?

Yahoo! Groups Links