Read / Write external flash using IAR

Hi all,

I'm having problems reading and writing the external flash of the
AT91RM9200-EK that uses an AT49BV6416 with IAR.
- First of all, I haven't been able to find more information about
the JLink, as I'm not so sure that the debugger will allow me at all
to read / write in memory, the same memory in where all the debug
information seats.

- I have used the initialization suggested by the sample code;
void AT91F_InitFlash()
{
AT91C_BASE_MC->MC_PUIA[0] AT91C_MC_PROT_PRWURW; //AT91C_MC_PROT_PNAUNA;
AT91C_BASE_MC->MC_PUP = 0;
AT91C_BASE_MC->MC_PUER = 0; //* Memory controller
protection unit disable
AT91C_BASE_MC->MC_ASR = 0; //* read only!
AT91C_BASE_MC->MC_AASR = 0; //* read only!

//* Setup MEMC to support CS0=Flash
AT91C_BASE_EBI->EBI_CSA |= AT91C_EBI_CS0A_SMC;
AT91C_BASE_EBI->EBI_CFGR = (AT91C_EBI_DBPUC & 0x00) |
(AT91C_EBI_EBSEN & 0x00);

//* Setup Flash
AT91C_BASE_SMC2->SMC2_CSR[0] = (AT91C_SMC2_NWS & 0x4) |
AT91C_SMC2_WSEN
| (AT91C_SMC2_TDF &
0x200) | AT91C_SMC2_BAT | AT91C_SMC2_DBW_16;
}

I have changed the first setting in where the memory was protected
using
AT91C_MC_PROT_PNAUNA ((unsigned int) 0x0) // (MC) Privilege: No
Access, User: No Access
And I replaced it with ..
AT91C_MC_PROT_PRWURW ((unsigned int) 0x3) // (MC) Privilege:
Read/Write, User: Read/Write

Now, if I debug it through and I try to read the manufacturer for
example, using step by step, the code goes through it but the
information read is wrong and if I run it from reset, it hung at the
reading the id-manufacturer instruction I think??

(*((volatile unsigned short *)(base_adr + (0x0555 << 1)) = 0xAA;
(*((volatile unsigned short *)(base_adr + (0x0AAA << 1)) = 0x55;
(*((volatile unsigned short *)(base_adr + (0x0555 << 1)) = 0x90;

manuf_code = (*((volatile unsigned short *)(0x10000000);
device_code = (*((volatile unsigned short *)(0x10000000 + 2);

(*((volatile unsigned short *)(base_adr + (0x0555 << 1)) = 0xAA;
(*((volatile unsigned short *)(base_adr + (0x0AAA << 1)) = 0x55;
(*((volatile unsigned short *)(base_adr + (0x0555 << 1)) = 0xF0;

- If I also try to erase a sector by using..
(*((volatile unsigned short * )(base_adr + (0x0555 << 1)) = 0xAA;
(*((volatile unsigned short * ) (base_adr + (0x0AAA << 1)) = 0x55;
(*((volatile unsigned short * ) (base_adr + (0x0555 << 1)) = 0x80;
(*((volatile unsigned short * ) (base_adr + (0x0555 << 1)) = 0xAA;
(*((volatile unsigned short * ) (base_adr + (0x0AAA << 1)) = 0x55;
(*((volatile unsigned short * ) (adr) = 0x30;
return (Polling(adr)); // Wait until Erase completed

Pulling() should return `OK' after reading erase-complete flags, but
ones again if I debug it step by step it passes ok but if I run it
from reset it will hang.

It may be out there a Guru that hopefully will be able to give me
some advice.

Leo Start a New Thread

Hi,

I'm not 100% famailiar with the AT91RM9200, but I presume it's a ROMless with a 16 bit bus.
In that case I expect the MMU to default to lots of wait states so you can boot of your flash
(providing the HW is set to strap for proper bus width and mem alignment).
If that is the case too, then I would look at my startup code.
The debugger shouldnt affect your system, as it takes control via the JTAG.

Perhaps your startup code sets up the wait states incorrectly for your AT49BV6416 Flash ?
Again, this is conjecture, I'm not familiar with the RM9200-EK.

But really, the AT91F_InitFlash() function part that sets up your flash should be the very first
thing that's executed, IOW done in low level (ASM) at start up.
If this not the case, it would explain why stepping with the debugger will work, but executing at
full speed hangs the code.

Best Regards,
Kris

________________________________________
From: A... [mailto:A...] On Behalf Of leoinpatagonia
Sent: Wednesday, 14 February 2007 9:09 PM
To: A...
Subject: [AT91SAM] Read / Write external flash using IAR

Hi all,

I'm having problems reading and writing the external flash of the
AT91RM9200-EK that uses an AT49BV6416 with IAR.
- First of all, I haven't been able to find more information about
the JLink, as I'm not so sure that the debugger will allow me at all
to read / write in memory, the same memory in where all the debug
information seats.

- I have used the initialization suggested by the sample code;
void AT91F_InitFlash()
{
AT91C_BASE_MC->MC_PUIA[0] AT91C_MC_PROT_PRWURW; //AT91C_MC_PROT_PNAUNA;
AT91C_BASE_MC->MC_PUP = 0;
AT91C_BASE_MC->MC_PUER = 0; //* Memory controller
protection unit disable
AT91C_BASE_MC->MC_ASR = 0; //* read only!
AT91C_BASE_MC->MC_AASR = 0; //* read only!

//* Setup MEMC to support CS0=Flash
AT91C_BASE_EBI->EBI_CSA |= AT91C_EBI_CS0A_SMC;
AT91C_BASE_EBI->EBI_CFGR = (AT91C_EBI_DBPUC & 0x00) |
(AT91C_EBI_EBSEN & 0x00);

//* Setup Flash
AT91C_BASE_SMC2->SMC2_CSR[0] = (AT91C_SMC2_NWS & 0x4) |
AT91C_SMC2_WSEN
| (AT91C_SMC2_TDF &
0x200) | AT91C_SMC2_BAT | AT91C_SMC2_DBW_16;
}

I have changed the first setting in where the memory was protected
using
AT91C_MC_PROT_PNAUNA ((unsigned int) 0x0) // (MC) Privilege: No
Access, User: No Access
And I replaced it with ..
AT91C_MC_PROT_PRWURW ((unsigned int) 0x3) // (MC) Privilege:
Read/Write, User: Read/Write

Now, if I debug it through and I try to read the manufacturer for
example, using step by step, the code goes through it but the
information read is wrong and if I run it from reset, it hung at the
reading the id-manufacturer instruction I think??

(*((volatile unsigned short *)(base_adr + (0x0555 << 1)) = 0xAA;
(*((volatile unsigned short *)(base_adr + (0x0AAA << 1)) = 0x55;
(*((volatile unsigned short *)(base_adr + (0x0555 << 1)) = 0x90;

manuf_code = (*((volatile unsigned short *)(0x10000000);
device_code = (*((volatile unsigned short *)(0x10000000 + 2);

(*((volatile unsigned short *)(base_adr + (0x0555 << 1)) = 0xAA;
(*((volatile unsigned short *)(base_adr + (0x0AAA << 1)) = 0x55;
(*((volatile unsigned short *)(base_adr + (0x0555 << 1)) = 0xF0;

- If I also try to erase a sector by using..
(*((volatile unsigned short * )(base_adr + (0x0555 << 1)) = 0xAA;
(*((volatile unsigned short * ) (base_adr + (0x0AAA << 1)) = 0x55;
(*((volatile unsigned short * ) (base_adr + (0x0555 << 1)) = 0x80;
(*((volatile unsigned short * ) (base_adr + (0x0555 << 1)) = 0xAA;
(*((volatile unsigned short * ) (base_adr + (0x0AAA << 1)) = 0x55;
(*((volatile unsigned short * ) (adr) = 0x30;
return (Polling(adr)); // Wait until Erase completed

Pulling() should return `OK' after reading erase-complete flags, but
ones again if I debug it step by step it passes ok but if I run it
from reset it will hang.

It may be out there a Guru that hopefully will be able to give me
some advice.

Leo Start a New Thread

Hi Kris,

Thanks for your comments.

I have moved the init function as close as possible to the startup and
it hasn't made much difference yet.

At the moment (I think) I can Read the flash when I use a pointer to any
memory location (at run time without hanging), after said that, the only
think I read is pretty much data or rubbish (not sure), I did read the
first 20 sectors and it's never a single 0xFFFF, but I wouldn't imaging
that all that space (about 500Kbytes) is used to store either debug
information or data, when my app hardly is over 20K.

Once again I do have doubts about the way I'm addressing the memory as
it looks like I may be going in a loop.

For example for Erasing a sector; When sending out the commands, it
includes the base_address (0x10000000, that's where the flash is
mapped)..

(*((volatile unsigned short *)(base_adr + (0x0555 << 1)) = 0xAA, then
0x55, 0x80, 0x88 and 0x55..

...And when it sends out the address of the sector to be erased it does
it as follow..

(*((volatile unsigned short * ) (adr) = 0x30;

where adr could be 0x00008000 for sec number 8, and it doesn't include
the base address!!!, is that correct??? Same rule applies for Unlock
Sector, Program, Read...

Regards

Leo

-----Original Message-----
From: Microbit [mailto:m...@optusnet.com.au]
Sent: 14 February 2007 14:50
To: A...
Subject: RE: [AT91SAM] Read / Write external flash using IAR

Hi,

I'm not 100% famailiar with the AT91RM9200, but I presume it's a ROMless
with a 16 bit bus.
In that case I expect the MMU to default to lots of wait states so you
can boot of your flash
(providing the HW is set to strap for proper bus width and mem
alignment).
If that is the case too, then I would look at my startup code.
The debugger shouldn't affect your system, as it takes control via the
JTAG.

Perhaps your startup code sets up the wait states incorrectly for your
AT49BV6416 Flash ?
Again, this is conjecture, I'm not familiar with the RM9200-EK.

But really, the AT91F_InitFlash() function part that sets up your flash
should be the very first
thing that's executed, IOW done in low level (ASM) at start up.
If this not the case, it would explain why stepping with the debugger
will work, but executing at
full speed hangs the code.

Best Regards,
Kris

________________________________________
From: A...
[mailto:A... ] On
Behalf Of leoinpatagonia
Sent: Wednesday, 14 February 2007 9:09 PM
To: A...
Subject: [AT91SAM] Read / Write external flash using IAR

Hi all,

I'm having problems reading and writing the external flash of the
AT91RM9200-EK that uses an AT49BV6416 with IAR.
- First of all, I haven't been able to find more information about
the JLink, as I'm not so sure that the debugger will allow me at all
to read / write in memory, the same memory in where all the debug
information seats.

- I have used the initialization suggested by the sample code;
void AT91F_InitFlash()
{
AT91C_BASE_MC->MC_PUIA[0] AT91C_MC_PROT_PRWURW; //AT91C_MC_PROT_PNAUNA;
AT91C_BASE_MC->MC_PUP = 0;
AT91C_BASE_MC->MC_PUER = 0; //* Memory controller
protection unit disable
AT91C_BASE_MC->MC_ASR = 0; //* read only!
AT91C_BASE_MC->MC_AASR = 0; //* read only!

//* Setup MEMC to support CS0=Flash
AT91C_BASE_EBI->EBI_CSA |= AT91C_EBI_CS0A_SMC;
AT91C_BASE_EBI->EBI_CFGR = (AT91C_EBI_DBPUC & 0x00) |
(AT91C_EBI_EBSEN & 0x00);

//* Setup Flash
AT91C_BASE_SMC2->SMC2_CSR[0] = (AT91C_SMC2_NWS & 0x4) |
AT91C_SMC2_WSEN
| (AT91C_SMC2_TDF &
0x200) | AT91C_SMC2_BAT | AT91C_SMC2_DBW_16;
}

I have changed the first setting in where the memory was protected
using
AT91C_MC_PROT_PNAUNA ((unsigned int) 0x0) // (MC) Privilege: No
Access, User: No Access
And I replaced it with ..
AT91C_MC_PROT_PRWURW ((unsigned int) 0x3) // (MC) Privilege:
Read/Write, User: Read/Write

Now, if I debug it through and I try to read the manufacturer for
example, using step by step, the code goes through it but the
information read is wrong and if I run it from reset, it hung at the
reading the id-manufacturer instruction I think??

(*((volatile unsigned short *)(base_adr + (0x0555 << 1)) = 0xAA;
(*((volatile unsigned short *)(base_adr + (0x0AAA << 1)) = 0x55;
(*((volatile unsigned short *)(base_adr + (0x0555 << 1)) = 0x90;

manuf_code = (*((volatile unsigned short *)(0x10000000);
device_code = (*((volatile unsigned short *)(0x10000000 + 2);

(*((volatile unsigned short *)(base_adr + (0x0555 << 1)) = 0xAA;
(*((volatile unsigned short *)(base_adr + (0x0AAA << 1)) = 0x55;
(*((volatile unsigned short *)(base_adr + (0x0555 << 1)) = 0xF0;

- If I also try to erase a sector by using..
(*((volatile unsigned short * )(base_adr + (0x0555 << 1)) = 0xAA;
(*((volatile unsigned short * ) (base_adr + (0x0AAA << 1)) = 0x55;
(*((volatile unsigned short * ) (base_adr + (0x0555 << 1)) = 0x80;
(*((volatile unsigned short * ) (base_adr + (0x0555 << 1)) = 0xAA;
(*((volatile unsigned short * ) (base_adr + (0x0AAA << 1)) = 0x55;
(*((volatile unsigned short * ) (adr) = 0x30;
return (Polling(adr)); // Wait until Erase completed

Pulling() should return `OK' after reading erase-complete flags, but
ones again if I debug it step by step it passes ok but if I run it
from reset it will hang.

It may be out there a Guru that hopefully will be able to give me
some advice.

Leo

***This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.

If you have received this email in error please notify the system manager.

This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

International Sportsworld Communicators Ltd*** Start a New Thread

Hi Leo,

> sure), I did read the first 20 sectors and its never a single 0xFFFF, but I wouldnt imaging
> that all that space (about 500Kbytes) is used to store either debug information or data, when my
> app hardly is over 20K.

Debug information is never stored in the target, that's only in symbol tables on PC for the
debugger to correlate symbols with addresses and so forth.
If your app is ~ 20K, then the reason you have "junk" beyond app's 20K or so is probably because
the sectors not used by the app haven't been erased. There might be an option to "erase all"
before flashing the target.
Perhaps simply try to write - in runtime - specific sequences of bytes/words, and see if you can
read them back properly. This can initially be a pain, because you need to make sure that "you
know that you know where you wrote it" ...and so on... (if you know what I mean :-)

> I have moved the init function as close as possible to the startup and it hasnt made much
> difference yet.

If you can _guarantee_ that your flash isnt accessed until your init code (in C) is executed,
then that's OK - but I presume that your startup code resides in that very Flash part, which means
that your startup code MUST setup the MMU to properly access Flash....
So you MUST set up your Flash access in ASM at startup. (unless - as before - the default is ample
wait state so you can strap from the Flash/EPROM/ROM, which is what I would expect with any
romless MCU)

Another possibility is that your startup code is fine for your flash (else it wouldn't execute if
it's in flash, would it :-) and your C init code buggers it up.
Try commenting out the init_flash() stuff, and see how that goes.

You should be able to track down the culprit in a pragmatic way, step by step.
Eg, follow your startup code by a simple LED flash loop w/ SW delay and see if you can execute it
from cold reset out of Flash. Once you have that going you can go from there etc.

> where adr could be 0x00008000 for sec number 8, and it doesnt include the base address!!!, is
> that correct??? Same rule applies for Unlock Sector, Program, Read

It's a long time ago I played with parallel Flash on a bus, and that was with SST 256 byte sector
1 & 2 MB flash - but I presume they all operate the same way :
To lock/unlock your sequences are written to specific addresses on the Flash, so that means you
need to write _absolute_ addresses IOW the base address SHOULD be included AFAIK....

Perhaps start fresh, do the LED flash thing and step it up from there, I'm sure you'll isolate the
problem soon enough.

HTH
73s & Best Regards,
Kris

________________________________________
From: A... [mailto:A...] On Behalf Of Leonardo Ferrari
Sent: Thursday, 15 February 2007 3:24 AM
To: A...
Subject: RE: [AT91SAM] Read / Write external flash using IAR

Hi Kris,

Thanks for your comments.
I have moved the init function as close as possible to the startup and it hasnt made much
difference yet.

At the moment (I think) I can Read the flash when I use a pointer to any memory location (at run
time without hanging), after said that, the only think I read is pretty much data or rubbish (not
sure), I did read the first 20 sectors and its never a single 0xFFFF, but I wouldnt imaging that
all that space (about 500Kbytes) is used to store either debug information or data, when my app
hardly is over 20K.

Once again I do have doubts about the way Im addressing the memory as it looks like I may be
going in a loop.
For example for Erasing a sector; When sending out the commands, it includes the base_address
(0x10000000, thats where the flash is mapped)..

(*((volatile unsigned short *)(base_adr + (0x0555 << 1)) = 0xAA, then 0x55, 0x80, 0x88 and 0x55..

And when it sends out the address of the sector to be erased it does it as follow..

(*((volatile unsigned short * ) (adr) = 0x30;

where adr could be 0x00008000 for sec number 8, and it doesnt include the base address!!!, is
that correct??? Same rule applies for Unlock Sector, Program, Read

Regards

Leo










-----Original Message-----
From: Microbit [mailto:m...@optusnet.com.au]
Sent: 14 February 2007 14:50
To: A...
Subject: RE: [AT91SAM] Read / Write external flash using IAR

Hi,

I'm not 100% famailiar with the AT91RM9200, but I presume it's a ROMless with a 16 bit bus.
In that case I expect the MMU to default to lots of wait states so you can boot of your flash
(providing the HW is set to strap for proper bus width and mem alignment).
If that is the case too, then I would look at my startup code.
The debugger shouldnt affect your system, as it takes control via the JTAG.

Perhaps your startup code sets up the wait states incorrectly for your AT49BV6416 Flash ?
Again, this is conjecture, I'm not familiar with the RM9200-EK.

But really, the AT91F_InitFlash() function part that sets up your flash should be the very first
thing that's executed, IOW done in low level (ASM) at start up.
If this not the case, it would explain why stepping with the debugger will work, but executing at
full speed hangs the code.

Best Regards,
Kris

________________________________________
From: A... [mailto:A...] On Behalf Of leoinpatagonia
Sent: Wednesday, 14 February 2007 9:09 PM
To: A...
Subject: [AT91SAM] Read / Write external flash using IAR

Hi all,

I'm having problems reading and writing the external flash of the
AT91RM9200-EK that uses an AT49BV6416 with IAR.
- First of all, I haven't been able to find more information about
the JLink, as I'm not so sure that the debugger will allow me at all
to read / write in memory, the same memory in where all the debug
information seats.

- I have used the initialization suggested by the sample code;
void AT91F_InitFlash()
{
AT91C_BASE_MC->MC_PUIA[0] AT91C_MC_PROT_PRWURW; //AT91C_MC_PROT_PNAUNA;
AT91C_BASE_MC->MC_PUP = 0;
AT91C_BASE_MC->MC_PUER = 0; //* Memory controller
protection unit disable
AT91C_BASE_MC->MC_ASR = 0; //* read only!
AT91C_BASE_MC->MC_AASR = 0; //* read only!

//* Setup MEMC to support CS0=Flash
AT91C_BASE_EBI->EBI_CSA |= AT91C_EBI_CS0A_SMC;
AT91C_BASE_EBI->EBI_CFGR = (AT91C_EBI_DBPUC & 0x00) |
(AT91C_EBI_EBSEN & 0x00);

//* Setup Flash
AT91C_BASE_SMC2->SMC2_CSR[0] = (AT91C_SMC2_NWS & 0x4) |
AT91C_SMC2_WSEN
| (AT91C_SMC2_TDF &
0x200) | AT91C_SMC2_BAT | AT91C_SMC2_DBW_16;
}

I have changed the first setting in where the memory was protected
using
AT91C_MC_PROT_PNAUNA ((unsigned int) 0x0) // (MC) Privilege: No
Access, User: No Access
And I replaced it with ..
AT91C_MC_PROT_PRWURW ((unsigned int) 0x3) // (MC) Privilege:
Read/Write, User: Read/Write

Now, if I debug it through and I try to read the manufacturer for
example, using step by step, the code goes through it but the
information read is wrong and if I run it from reset, it hung at the
reading the id-manufacturer instruction I think??

(*((volatile unsigned short *)(base_adr + (0x0555 << 1)) = 0xAA;
(*((volatile unsigned short *)(base_adr + (0x0AAA << 1)) = 0x55;
(*((volatile unsigned short *)(base_adr + (0x0555 << 1)) = 0x90;

manuf_code = (*((volatile unsigned short *)(0x10000000);
device_code = (*((volatile unsigned short *)(0x10000000 + 2);

(*((volatile unsigned short *)(base_adr + (0x0555 << 1)) = 0xAA;
(*((volatile unsigned short *)(base_adr + (0x0AAA << 1)) = 0x55;
(*((volatile unsigned short *)(base_adr + (0x0555 << 1)) = 0xF0;

- If I also try to erase a sector by using..
(*((volatile unsigned short * )(base_adr + (0x0555 << 1)) = 0xAA;
(*((volatile unsigned short * ) (base_adr + (0x0AAA << 1)) = 0x55;
(*((volatile unsigned short * ) (base_adr + (0x0555 << 1)) = 0x80;
(*((volatile unsigned short * ) (base_adr + (0x0555 << 1)) = 0xAA;
(*((volatile unsigned short * ) (base_adr + (0x0AAA << 1)) = 0x55;
(*((volatile unsigned short * ) (adr) = 0x30;
return (Polling(adr)); // Wait until Erase completed

Pulling() should return `OK' after reading erase-complete flags, but
ones again if I debug it step by step it passes ok but if I run it
from reset it will hang.

It may be out there a Guru that hopefully will be able to give me
some advice.

Leo
***This email and any files transmitted with it are confidential and intended solely for the use
of the individual or entity to whom they are addressed.

If you have received this email in error please notify the system manager.

This message contains confidential information and is intended only for the individual named. If
you are not the named addressee you should not disseminate, distribute or copy this e-mail.

International Sportsworld Communicators Ltd*** Start a New Thread

Hi Kris,

Thanks for you comments.
Yes, you were right in two things, I needed to start from fresh which I did and it has helped at a lot.

Your next suggestion of using absolute address worked well so far;
Im able to read any part of the flash successfully and I can even see where my code seats (first ~20K) and also after that, I only read 0xFFFF as expected, so far so good.

I also have been able to write one (short 0xXXXX or a char 0xXX) onto the first address of any of the no-used sectors and thats where my luck ends, right after that very instruction

(*((volatile unsigned short *) (base_adr + adr) = *(unsigned short *) buf;

..it goes nowhere to be seen , if I use the debug, it goes pass, but if I run the from reset, it just hangs, the strange part of it is that the data has been stored and if I reset the program, then if I do address that memory location and read it, the info is there!!

The same effect happens if I try to erase a sector, as soon as it executes the following instruction

(*((volatile unsigned short *) (base_adr + adr) = 0x30;

.. it hangs as well, but once again, the sector has been erased!!

I have been trying to modify the way of addressing to the memory location but with no success.

I wonder if some out there has tried it in asm, it may be another way, unless Im still doing something wrong with the command lines.

Regards

Leo Start a New Thread

Hi Leo,

> I also have been able to write one (short 0xXXXX or a char 0xXX) onto the first address of any
> of the no-used sectors and that's where my luck ends, right after that very instruction.
> (*((volatile unsigned short *) (base_adr + adr) = *(unsigned short *) buf;

Have you checked that your address is a multiple of 4 ?
If you write a short or a int/long on ARM it must be aligned on a 4 byte boundary, else you will
get a dabort error.
Either write it as 2 separate (H/L) bytes, or you have to ensure the compiler generates code that
writes it aligned - there's several ways to ensure the alignment in C.

Best Regards,
Kris

-----Original Message-----
From: A... [mailto:A...] On Behalf Of l...@iscrally.com
Sent: Friday, 16 February 2007 4:31 AM
To: A...
Subject: [AT91SAM] RE: Read / Write external flash using IAR

Hi Kris,

Thanks for you comments.
Yes, you were right in two things, I needed to start from fresh which I did and it has helped at a
lot.

Your next suggestion of using absolute address worked well so far;
I'm able to read any part of the flash successfully and I can even see where my code seats (first
~20K) and also after that, I only read 0xFFFF as expected, so far so good.

I also have been able to write one (short 0xXXXX or a char 0xXX) onto the first address of any of
the no-used sectors and that's where my luck ends, right after that very instruction.

(*((volatile unsigned short *) (base_adr + adr) = *(unsigned short *) buf;

..it goes nowhere to be seen , if I use the debug, it goes pass, but if I run the from
reset, it just hangs, the strange part of it is that the data has been stored and if I reset the
program, then if I do address that memory location and read it, the info is there!!

The same effect happens if I try to erase a sector, as soon as it executes the following
instruction.

(*((volatile unsigned short *) (base_adr + adr) = 0x30;

.. it hangs as well, but once again, the sector has been erased!!

I have been trying to modify the way of addressing to the memory location but with no success.

I wonder if some out there has tried it in asm, it may be another way, unless I'm still doing
something wrong with the command lines.

Regards

Leo

Yahoo! Groups Links Start a New Thread

Oh, and I forgot, when writing to Flash you must execute from RAM if your code is executing from
the same Flash as the one where your code is.
You can get special Flash that is "dual bank" or simply sit the code in your RAM.
If putting in RAM, that means also your INT ISRs have to be in RAM, unless you can guarantee that
interrupts are disables while you write your Flash.
On GCC to store in RAM you attribute your functions to be "fast" section. I don't know which
compiler you are using.

Best Regards,
Kris

-----Original Message-----
From: A... [mailto:A...] On Behalf Of l...@iscrally.com
Sent: Friday, 16 February 2007 4:31 AM
To: A...
Subject: [AT91SAM] RE: Read / Write external flash using IAR

Hi Kris,

Thanks for you comments.
Yes, you were right in two things, I needed to start from fresh which I did and it has helped at a
lot.

Your next suggestion of using absolute address worked well so far;
I'm able to read any part of the flash successfully and I can even see where my code seats (first
~20K) and also after that, I only read 0xFFFF as expected, so far so good.

I also have been able to write one (short 0xXXXX or a char 0xXX) onto the first address of any of
the no-used sectors and that's where my luck ends, right after that very instruction.

(*((volatile unsigned short *) (base_adr + adr) = *(unsigned short *) buf;

..it goes nowhere to be seen , if I use the debug, it goes pass, but if I run the from
reset, it just hangs, the strange part of it is that the data has been stored and if I reset the
program, then if I do address that memory location and read it, the info is there!!

The same effect happens if I try to erase a sector, as soon as it executes the following
instruction.

(*((volatile unsigned short *) (base_adr + adr) = 0x30;

.. it hangs as well, but once again, the sector has been erased!!

I have been trying to modify the way of addressing to the memory location but with no success.

I wonder if some out there has tried it in asm, it may be another way, unless I'm still doing
something wrong with the command lines.

Regards

Leo

Yahoo! Groups Links Start a New Thread

Hi kris,

Once again, you were right!!, and many thanks for that.

>> Have you checked that your address is a multiple of 4 ?
I checked the addressing of the code and it was all correct, always using (unsigned shorts).

>>, when writing to Flash you must execute from RAM if your code is executing from
the same Flash as the one where your code is.
That made lots of difference after I changed it, I used __ramfunc key-word to ensure my code is executed from ram at the point it writes commands to flash.

At that point I had Init(), Read(), Write(), Product_ID() and Unlock() working so far, the only function that was still giving me trouble was Sector_Earse() and by disabling the interrupts while in use proved to work well.

Many thanks again for your advice.

Leo Start a New Thread