Hi Anders, and thanks for your reply !

Patrick

--- In m..., Anders Lindgren wrote:
>
> Hi!
>
> It is the library that is does things incorrectly.
>
> If a module populates the segment DATA16_I, it *must* also populate the
> DATA16_ID segment. This segment is placed in read-only memory, at
> startup, the content of the _ID segment is copied to the corresponding
> _I segment.
>
> Normally, if a module wants to plain data it could use DATA16_Z, in
> which case the object is cleared at startup, or DATA16_N, which leaves
> the data uninitialized.
>
> Admittedly, a diagnostic message could probably have helped in this
> case. This could probably be solved by adding a range-checking directive
> to cstartup.s43 -- I will investigate this, if it is feasible I will add it.
>
> Sincerely,
> Anders Lindgren, IAR Systems, Author of the MSP430 compiler
> --
> Disclaimer: Opinions expressed in this posting are strictly my own and
> not necessarily those of my employer.
>

Beginning Microcontrollers with the MSP430

Are you a lilliputian?

From: m... [mailto:m...] On Behalf Of Paul Curtis
Sent: Thursday, February 14, 2013 4:18 PM
To: m...
Subject: Re: [msp430] Array initialization problem in IAR

On 14 Feb 2013, at 21:14, "Redd, Emmett R" E...@MissouriState.edu > wrote:

> I think the original Endian was discovered by some British traveler. And, this subject is probably appropriate for discussion on Yahoo.com.
>

Indeed, us Brits are known for our travelling escapades! I consider myself endian-neutral because I like my eggs scrambled, and served wet, on toast.

Regards,

-- Paul.

On 2013-02-15 15:00, distantship101 wrote:
> I've since solved the problem. My project includes the "VLO_Library.s43"
> code from TI that contains the following declaration :
>
> RSEG DATA16_I
> TI_8MHz_Counts_Per_VLO_Clock DS 2
>
> In the link map, I see that this variable is at 0x200 and T (my table)
> is at 0x202. The segment containing the initialization data is at 0x1100
> and contains :
>
> 01 00 02 00 03 00 04 00
>
> And so T ends up at 0x200 instead of 0x202.
>
> Changing the declaration in "VLO_Library.s43" to "RSEG DATA16_N" solves
> the problem, but leaves me with two questions :
>
> 1) Who's to blame ? TI (for using DS in DATA16_I) or IAR linker (for
> getting confused) ?
>
> 2) If using DS 2 in DATA16_I is incorrect, shouldn't I get a warning
> from either the assembler or linker (I have all diagnostics turned on).

Hi!

It is the library that is does things incorrectly.

If a module populates the segment DATA16_I, it *must* also populate the
DATA16_ID segment. This segment is placed in read-only memory, at
startup, the content of the _ID segment is copied to the corresponding
_I segment.

Normally, if a module wants to plain data it could use DATA16_Z, in
which case the object is cleared at startup, or DATA16_N, which leaves
the data uninitialized.

Admittedly, a diagnostic message could probably have helped in this
case. This could probably be solved by adding a range-checking directive
to cstartup.s43 -- I will investigate this, if it is feasible I will add it.

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

--- In m..., David McMinn wrote:
>
> On 14/02/2013 18:24, distantship101 wrote:
>
> What version of IAR are you using and what settings do you have? Your
> test code works as expected here (5.40.7, target 249, optimisations off,
> debug mode, running on simulator).

Hi David, and thanks for taking the time to try my test case, which turned out to be to simple to exhibit the problem.

I'm using an older version : IAR C/C++ Compiler for MSP430, 4.20.5 (4.20.5.50032). I originally noticed the problem when targeting an actual 2616, but managed to replicate it with the 249 running on simulator.

I've since solved the problem. My project includes the "VLO_Library.s43" code from TI that contains the following declaration :

RSEG DATA16_I
TI_8MHz_Counts_Per_VLO_Clock DS 2

In the link map, I see that this variable is at 0x200 and T (my table) is at 0x202. The segment containing the initialization data is at 0x1100 and contains :

01 00 02 00 03 00 04 00

And so T ends up at 0x200 instead of 0x202.

Changing the declaration in "VLO_Library.s43" to "RSEG DATA16_N" solves the problem, but leaves me with two questions :

1) Who's to blame ? TI (for using DS in DATA16_I) or IAR linker (for getting confused) ?

2) If using DS 2 in DATA16_I is incorrect, shouldn't I get a warning from either the assembler or linker (I have all diagnostics turned on).

Thanks

Patrick

On 14/02/2013 18:24, distantship101 wrote:

> In IAR, with the following code (full code of a test case at end of
> message)

[snip]

> Is this a problem in the initialization code, or is there something
> wrong with my code (which works fine in gcc in Mac OS X) ?

What version of IAR are you using and what settings do you have? Your
test code works as expected here (5.40.7, target 249, optimisations off,
debug mode, running on simulator).

Bovril came before Marmite, although it's more a beef extract than
Yeast, and is certainly better tasting. Can't have football (real
football) in scotland without hot bovril to drink.

Marmite came along in 1902, followed much later by Vegemite in 1923, but
despite it's iconic status in Australia now (even though it's been
bought out by those dastardly American chappies), it was unpopular until
the company started giving away imported Pontiacs as prizes, since then
you'd think it's been here since before colonisation.

As a much travelled native brit (120+ countries that I've spent at least
a whole day in) it's one thing I've never missed, unlike well made
scambled eggs, which should be slightly wet, so that unskilled non brits
drop them in their laps when the soggy toast gives way.

Al

On 15/02/2013 11:46 AM, Jon Kirwan wrote:
> On Thu, 14 Feb 2013 21:17:39 +0000, Paul wrote:
>
>> On 14 Feb 2013, at 21:14, "Redd, Emmett R" wrote:
>>
>>> I think the original Endian was discovered by some British
>>> traveler. And, this subject is probably appropriate for
>>> discussion on Yahoo.com.
>> Indeed, us Brits are known for our travelling escapades! I
>> consider myself endian-neutral because I like my eggs
>> scrambled, and served wet, on toast.
> Ughh. And here I'm still trying to get over visualizing Brits
> eating Marmite. Now I'm imagining still-wet eggs and marmite
> on toast..
>
> shudder...
>
> Jon
>

On Thu, 14 Feb 2013 21:17:39 +0000, Paul wrote:

>On 14 Feb 2013, at 21:14, "Redd, Emmett R" wrote:
>
>> I think the original Endian was discovered by some British
>> traveler. And, this subject is probably appropriate for
>> discussion on Yahoo.com.
>
> Indeed, us Brits are known for our travelling escapades! I
> consider myself endian-neutral because I like my eggs
> scrambled, and served wet, on toast.

Ughh. And here I'm still trying to get over visualizing Brits
eating Marmite. Now I'm imagining still-wet eggs and marmite
on toast..

shudder...

Jon

On 14 Feb 2013, at 21:14, "Redd, Emmett R" wrote:

> I think the original Endian was discovered by some British traveler. And, this subject is probably appropriate for discussion on Yahoo.com.
>

Indeed, us Brits are known for our travelling escapades! I consider myself endian-neutral because I like my eggs scrambled, and served wet, on toast.

Regards,

-- Paul.

I think the original Endian was discovered by some British traveler. And, this subject is probably appropriate for discussion on Yahoo.com.

Emmett Redd, Ph.D., Professor mailto:E...@MissouriState.Edu
Physics, Astronomy, and Materials Science Office: 417-836-5221
Missouri State University Dept: 417-838-5131
901 S NATIONAL AVENUE FAX: 417-836-6226
SPRINGFIELD, MO 65897 USA Lab: 417-836-3770

It is clear that thought is not free if the profession of certain opinions make it impossible to earn a living. -- Bertrand Russell

> -----Original Message-----
> From: m... [mailto:m...] On Behalf
> Of Onestone
> Sent: Thursday, February 14, 2013 12:48 PM
> To: m...
> Subject: Re: [msp430] Array initialization problem in IAR
>
> American Endian or Asian?
>
> Al
>
> On 15/02/2013 4:57 AM, Redd, Emmett R wrote:
> > I am pretty sure that the MSP430 is Little Endian.
> >
> > Emmett Redd, Ph.D., Professor mailto:E...@MissouriState.Edu
> > Physics, Astronomy, and Materials Science Office: 417-836-5221
> > Missouri State University Dept: 417-838-5131
> > 901 S NATIONAL AVENUE FAX: 417-836-6226
> > SPRINGFIELD, MO 65897 USA Lab: 417-836-3770
> >
> > It is clear that thought is not free if the profession of certain
> > opinions make it impossible to earn a living. -- Bertrand Russell
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: m... [mailto:m...] On
> >> Behalf Of distantship101
> >> Sent: Thursday, February 14, 2013 12:25 PM
> >>
> >> If I look at the two bytes before, they are 01 00. It looks as if T
> >> was
> >
> >
> >
> >
> >
> >

American Endian or Asian?

Al

On 15/02/2013 4:57 AM, Redd, Emmett R wrote:
> I am pretty sure that the MSP430 is Little Endian.
>
> Emmett Redd, Ph.D., Professor mailto:E...@MissouriState.Edu
> Physics, Astronomy, and Materials Science Office: 417-836-5221
> Missouri State University Dept: 417-838-5131
> 901 S NATIONAL AVENUE FAX: 417-836-6226
> SPRINGFIELD, MO 65897 USA Lab: 417-836-3770
>
> It is clear that thought is not free if the profession of certain opinions make it impossible to earn a living. -- Bertrand Russell
>> -----Original Message-----
>> From: m... [mailto:m...] On Behalf
>> Of distantship101
>> Sent: Thursday, February 14, 2013 12:25 PM
>>
>> If I look at the two bytes before, they are 01 00. It looks as if T was
>
>