EmbeddedRelated.com
Forums
Memfault State of IoT Report

Can't write to flash memory

Started by ffredrik July 12, 2007
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.

Any idea? Is it a mapping issue?

Thanks
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?
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
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
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
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
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
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
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
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
>

Memfault State of IoT Report