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.
Array initialization problem in IAR
Started by ●February 14, 2013
Reply by ●February 18, 20132013-02-18
Reply by ●February 18, 20132013-02-18
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.
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.
Reply by ●February 18, 20132013-02-18
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.
>
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.
>
