EmbeddedRelated.com
Forums

Accesing Data on Flash

Started by gab0ar June 11, 2008
Hey Tom,

A propos, what's it like sharing your full name with the surname of the discoverer of Pluto ?
(Clyde Tombaugh).
I've always wondered whether your parents did this with intent as homage to Clyde :-)

B rgds
Kris

-----Original Message-----
From: m... [mailto:m...] On Behalf Of Tom Baugh
Sent: Friday, 13 June 2008 4:51 AM
To: m...
Subject: [msp430] Best Practices White Paper Re: Accesing Data on Flash

Beginning Microcontrollers with the MSP430

I resolved the problem placing the definition with the initialicers on
a separate .CPP while keeping an extern reference on the .h

In Example:

Create a Table.cpp with only

__root const tMyVar myVar @ MY_LOCATION = {
DEFAULT_VALUE
}

Then on the .h.
#define DEFAULT_VALUE 8
#define MY_LOCATION 0xF000

extern tMyVar myVar;

I know it isn't a nice solution, but it does the trick without
reviewing all the calls to the variable.
I still think there has to be a better solution but I just can't find it.

Thanks to all the people that took the time to respond.

Gabriel

--- In m..., Aaron Greer wrote:
>
> Make sure your optimizations are set to high (maximum) for size and
you should see the assignment from gamma to t be replaced with a
constant assignment to t.
> ----- Original Message -----
> From: "old_cow_yellow"
> To: m...
> Sent: Wednesday, June 11, 2008 6:15:03 PM (GMT-0700) America/Denver
> Subject: [msp430] Re: Accesing Data on Flash
>
> You are right. My mistake.
>
> BTW. The following:
>
> const int gamma @ 0xFC00 = 3;
> int main(void)
> {
> int t = gamma;
> return t;
> }
>
> seems to work too. I am confused.
>
> --- In m... , Aaron Greer wrote:
> >
> > OCY, you need to use __root like this:
> > __root const int _gamma @ 0xFC00 = 3;
> >
> >
> >
> > ----- Original Message -----
> > From: "old_cow_yellow"
> > To: m...
> > Sent: Wednesday, June 11, 2008 5:31:18 PM (GMT-0700) America/Denver
> > Subject: [msp430] Re: Accesing Data on Flash
> >
> >
> >
> >
> >
> >
> >
> > I tried it with a MSP430F2013 which has Flash at 0xF800 - 0xFFFF
> >
> > #include
> > const int _gamma @ 0xFC00 = 3;
> > #define gamma (*(int*)(0xFC00))
> > int main(void)
> > {
> > int t = gamma;
> > return t;
> > }
> >
> > The memory (Flash) dump shows:
> >
> > f800: 4031 0280 12b0 f80c 12b0 f82c 421c fc00
> > f810: 4130 4130 120a 8321 4c0a 4a81 0000 410e
> > f820: 435c 12b0 f812 3ff9 4030 f814 4030 f828
> > f830: ffff ffff ffff ffff ffff ffff ffff ffff
> > ........
> > fc00: ffff ffff ffff ffff ffff ffff ffff ffff
> > ........
> > fff0: ffff ffff ffff ffff ffff ffff ffff f800
> >
> > And when I single step it, I got t equal to 0xFFFF
> >
> > I then change to:
> >
> > #include
> > const int _gamma @ 0xF800 = 3;
> > #define gamma (*(int*)(0xF800))
> > int main(void)
> > {
> > int t = gamma;
> > return t;
> > }
> >
> > The memory dump changed to:
> >
> > f800: 4031 0280 12b0 f80c 12b0 f82c 421c fc80
> > f810: 4130 4130 120a 8321 4c0a 4a81 0000 410e
> > f820: 435c 12b0 f812 3ff9 4030 f814 4030 f828
> > f830: ffff ffff ffff ffff ffff ffff ffff ffff
> > ........
> > fc00: ffff ffff ffff ffff ffff ffff ffff ffff
> > ........
> > fff0: ffff ffff ffff ffff ffff ffff ffff f800
> >
> > And single step shows t equal to 0x4031.
> >
> > --- In m... , Aaron Greer wrote:
> > >
> > > OCY you haven't actually tried this, have you? You may be correct
> > about the address, I didn't check that, it came straight from an IAR
> > example. I do know however, that the syntax is correct for placing a
> > const value into flash at a known address. I recently completed an
> > application which had several const values in flash using this same
> > syntax. It worked perfectly as expected. You really should try it out
> > for yourself and see.
> > >
> >
> >
> >
> >
> >
>

I'd still like to know why IAR V3.42 won't compile with a volatile const declaration, especially when their very own example uses it.
----- Original Message -----
From: "gab0ar"
To: m...
Sent: Friday, June 13, 2008 6:17:58 AM (GMT-0700) America/Denver
Subject: [msp430] Re: Accesing Data on Flash

I resolved the problem placing the definition with the initialicers on
a separate .CPP while keeping an extern reference on the .h

In Example:

Create a Table.cpp with only

__root const tMyVar myVar @ MY_LOCATION = {
DEFAULT_VALUE
}

Then on the .h.

#define DEFAULT_VALUE 8
#define MY_LOCATION 0xF000

extern tMyVar myVar;

I know it isn't a nice solution, but it does the trick without
reviewing all the calls to the variable.
I still think there has to be a better solution but I just can't find it.

Thanks to all the people that took the time to respond.

Gabriel

--- In m... , Aaron Greer wrote:
>
> Make sure your optimizations are set to high (maximum) for size and
you should see the assignment from gamma to t be replaced with a
constant assignment to t.
> ----- Original Message -----
> From: "old_cow_yellow"
> To: m...
> Sent: Wednesday, June 11, 2008 6:15:03 PM (GMT-0700) America/Denver
> Subject: [msp430] Re: Accesing Data on Flash
>
> You are right. My mistake.
>
> BTW. The following:
>
> const int gamma @ 0xFC00 = 3;
> int main(void)
> {
> int t = gamma;
> return t;
> }
>
> seems to work too. I am confused.
>
> --- In m... , Aaron Greer wrote:
> >
> > OCY, you need to use __root like this:
> > __root const int _gamma @ 0xFC00 = 3;
> >
> >
> >
> > ----- Original Message -----
> > From: "old_cow_yellow"
> > To: m...
> > Sent: Wednesday, June 11, 2008 5:31:18 PM (GMT-0700) America/Denver
> > Subject: [msp430] Re: Accesing Data on Flash
> >
> >
> >
> >
> >
> >
> >
> > I tried it with a MSP430F2013 which has Flash at 0xF800 - 0xFFFF
> >
> > #include
> > const int _gamma @ 0xFC00 = 3;
> > #define gamma (*(int*)(0xFC00))
> > int main(void)
> > {
> > int t = gamma;
> > return t;
> > }
> >
> > The memory (Flash) dump shows:
> >
> > f800: 4031 0280 12b0 f80c 12b0 f82c 421c fc00
> > f810: 4130 4130 120a 8321 4c0a 4a81 0000 410e
> > f820: 435c 12b0 f812 3ff9 4030 f814 4030 f828
> > f830: ffff ffff ffff ffff ffff ffff ffff ffff
> > ........
> > fc00: ffff ffff ffff ffff ffff ffff ffff ffff
> > ........
> > fff0: ffff ffff ffff ffff ffff ffff ffff f800
> >
> > And when I single step it, I got t equal to 0xFFFF
> >
> > I then change to:
> >
> > #include
> > const int _gamma @ 0xF800 = 3;
> > #define gamma (*(int*)(0xF800))
> > int main(void)
> > {
> > int t = gamma;
> > return t;
> > }
> >
> > The memory dump changed to:
> >
> > f800: 4031 0280 12b0 f80c 12b0 f82c 421c fc80
> > f810: 4130 4130 120a 8321 4c0a 4a81 0000 410e
> > f820: 435c 12b0 f812 3ff9 4030 f814 4030 f828
> > f830: ffff ffff ffff ffff ffff ffff ffff ffff
> > ........
> > fc00: ffff ffff ffff ffff ffff ffff ffff ffff
> > ........
> > fff0: ffff ffff ffff ffff ffff ffff ffff f800
> >
> > And single step shows t equal to 0x4031.
> >
> > --- In m... , Aaron Greer wrote:
> > >
> > > OCY you haven't actually tried this, have you? You may be correct
> > about the address, I didn't check that, it came straight from an IAR
> > example. I do know however, that the syntax is correct for placing a
> > const value into flash at a known address. I recently completed an
> > application which had several const values in flash using this same
> > syntax. It worked perfectly as expected. You really should try it out
> > for yourself and see.
> > >
> >
> >
> >
> >
> >
>


You piqued my interest. I need a flash based file system for an
embedded system. Does your book have "nice warm fuzzies" (that reuire
me to purchase the real code for lots of $$$) or does it have the
code &&/|| enough design detail to make it work? The target chip is
NOT an msp430.

I have no need to remainder of the book. I would be buying it for
that one chapter. But it may still be worth it. If you say the book
is good enough, I will buy it and post my findings back to this
group. Thanks...

--- In m..., "Tom Baugh" wrote:
>
> Stuart,
>
> Great suggestion. Chapter 10 of our MSP430 RF book shows how to do
> this. That chapter is titled "Info Flash Drive", but the
techniques
> are suitable for the main flash as well. So, the chapter also
> discusses porting the techniques to the main flash.
>
> To find this book, search Amazon for MSP430 as one word, then choose
> our blue and white title from the list. Note the reviewer comment
> about this chapter, also.
>
> Tom
>
> > This is a subject that comes up again and again. I admit that it
> > usually takes me a few tries to get the syntax, linker files, etc.
> > just right whenever I need to keep data constant in flash.
> >
> > I would like to suggest to our friends at TI, IAR, and other
> > if they are reading, that they write a "Best Practices" white
paper
> > storing constant data in flash. I realize there are some
> > notes out there, but apparently none seem to fit the bill.
> > ...
> > Just a suggestions, chip and tool guys!
> >
> > Stuart
>
Ken,

Ch10 is for licensed users, but is reasonably separate from
everything else in the licensed code base. So, as a bonus for
participants in this group, if someone gets the RF book just for that
chapter, then contact us via the info email on our site and we will
arrange for releasing the info flash source code to purchasers of the
RF book upon proof of purchase.

The state machine book, on the other hand, has no licensed code.
That book works through all the source as part of the tutorials.

Tom

--- In m..., "Ken Rowberry" wrote:
>
> You piqued my interest. I need a flash based file system for an
> embedded system. Does your book have "nice warm fuzzies" (that
reuire
> me to purchase the real code for lots of $$$) or does it have the
> code &&/|| enough design detail to make it work? The target chip is
> NOT an msp430.
>
> I have no need to remainder of the book. I would be buying it for
> that one chapter. But it may still be worth it. If you say the book
> is good enough, I will buy it and post my findings back to this
> group. Thanks...
>
> --- In m..., "Tom Baugh" wrote:
> >
> > Stuart,
> >
> > Great suggestion. Chapter 10 of our MSP430 RF book shows how to
do
> > this. That chapter is titled "Info Flash Drive", but the
> techniques
> > are suitable for the main flash as well. So, the chapter also
> > discusses porting the techniques to the main flash.
> >
> > To find this book, search Amazon for MSP430 as one word, then
choose
> > our blue and white title from the list. Note the reviewer comment
> > about this chapter, also.
> >
> > Tom
> >
> > > This is a subject that comes up again and again. I admit that it
> > > usually takes me a few tries to get the syntax, linker files,
etc.
> > > just right whenever I need to keep data constant in flash.
> > >
> > > I would like to suggest to our friends at TI, IAR, and other
> > > if they are reading, that they write a "Best Practices" white
> paper
> > > storing constant data in flash. I realize there are some
> > > notes out there, but apparently none seem to fit the bill.
> > > ...
> > > Just a suggestions, chip and tool guys!
> > >
> > > Stuart
> > >
>
Aaron Greer wrote:

> I'd still like to know why IAR V3.42 won't compile with a volatile const
> declaration, especially when their very own example uses it.

Hi Aaron, and the rest of you!

Sorry for picking up an old thread like this, but it contained open issues.

The background for the change that was made in the compiler is that the
old behavior simply wasn't standard compliant. Footnote 112, in section
6.7.3 says:

"The implementation may place a const object that is not volatile in
a read-only region of storage".
The solution we recommend is the one Gabriel found, place the definition
of the variable in one file source and the declaration in another. This
solution has some drawbacks like it's still not possible to use the
"volatile" keyword.

Also, if you use the new "multifile compilation" (i.e. application-wide
optimizations) feature, you have to make sure that the source file that
contains the constant definitions are not included in the same group as
the rest of the files.

Ideally, I would like to find a better way to handle this since this is
something that people typically would like to do.

-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.