Hi all,
I make first attempts to work with FG4616, moving assembler code from F449.
Linker gives me 1 warning:
Warning[w29]: Parts of segment DATA16_N are initialized (as in module Mymain),
even though it is of type DATA (and
thus not promable)
I think this is due 'holes' between byte and word aligned zones.
When i invoke debugger - debugger finds target (TI-FET ,LPT) , downloads but
shows
errors as follow:
Verify error at address 0x11f9 on target 0x40 in file 0x0
Verify error at address 0x11ff on target 0x41 in file 0x0
Verify error at address 0x16cb on target 0x5c in file 0x0
Verify error at address 0x16ff on target 0xf5 in file 0x0
Verify error at address 0x11F9. Value should be 0x00 but is 0x40.
Verify error at address 0x11FF. Value should be 0x00 but is 0x41.
Verify error at address 0x16CB. Value should be 0x00 but is 0x5C.
Verify error at address 0x16FF. Value should be 0x00 but is 0xF5.
Failed to load debugee: C:\msp_f413\doser\Debug\Exe\doser.d43
Maybe i'm wrong , but these adreeses are in RAM, isn't it?
Why debugger fails?
regards
Stefan
430FG4616 IAR Debugger - Verify error
Started by ●March 25, 2009
Reply by ●March 26, 20092009-03-26
stefandk63 wrote:
> I make first attempts to work with FG4616, moving assembler code from F449.
> Linker gives me 1 warning:
> Warning[w29]: Parts of segment DATA16_N are initialized (as in module
> Mymain), even though it is of type DATA (and
> thus not promable)
> I think this is due 'holes' between byte and word aligned zones.
Hi Stefan!
I haven't seen this warning being triggered by something like that -- if
you can you make a small example that triggers the warning, I could take
a look at it.
-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.
> I make first attempts to work with FG4616, moving assembler code from F449.
> Linker gives me 1 warning:
> Warning[w29]: Parts of segment DATA16_N are initialized (as in module
> Mymain), even though it is of type DATA (and
> thus not promable)
> I think this is due 'holes' between byte and word aligned zones.
Hi Stefan!
I haven't seen this warning being triggered by something like that -- if
you can you make a small example that triggers the warning, I could take
a look at it.
-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.
Reply by ●March 27, 20092009-03-27
Anders Lindgren wrote:
> stefandk63 wrote:
> > I make first attempts to work with FG4616, moving assembler code from
> F449.
> > Linker gives me 1 warning:
> > Warning[w29]: Parts of segment DATA16_N are initialized (as in module
> > Mymain), even though it is of type DATA (and
> > thus not promable)
> > I think this is due 'holes' between byte and word aligned zones.
>
> Hi Stefan!
>
> I haven't seen this warning being triggered by something like that -- if
> you can you make a small example that triggers the warning, I could take
> a look at it.
>
> -- Anders Lindgren, IAR Systems
Hi Stefan!
I took a look at the code you sent me.
It appears as the cause of the problem is the "EVEN" directive. When it
aligns code, it emits a physical byte even though it is in a DATA segment.
As a work-around you can either align the code manually, or you can
start a new segment part for each variable that must be aligned. One
advantage of the latter is that it would allow the linker to throw out
unused variables.
In other words, you can write:
RSEG DATA16_N:DATA:REORDER:NOROOT(1)
foo: DS 2
The "1" in the RSEG directive says that the segment part should be
aligned at an even 2^1 = 2 bytes.
-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.
> stefandk63 wrote:
> > I make first attempts to work with FG4616, moving assembler code from
> F449.
> > Linker gives me 1 warning:
> > Warning[w29]: Parts of segment DATA16_N are initialized (as in module
> > Mymain), even though it is of type DATA (and
> > thus not promable)
> > I think this is due 'holes' between byte and word aligned zones.
>
> Hi Stefan!
>
> I haven't seen this warning being triggered by something like that -- if
> you can you make a small example that triggers the warning, I could take
> a look at it.
>
> -- Anders Lindgren, IAR Systems
Hi Stefan!
I took a look at the code you sent me.
It appears as the cause of the problem is the "EVEN" directive. When it
aligns code, it emits a physical byte even though it is in a DATA segment.
As a work-around you can either align the code manually, or you can
start a new segment part for each variable that must be aligned. One
advantage of the latter is that it would allow the linker to throw out
unused variables.
In other words, you can write:
RSEG DATA16_N:DATA:REORDER:NOROOT(1)
foo: DS 2
The "1" in the RSEG directive says that the segment part should be
aligned at an even 2^1 = 2 bytes.
-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.
Reply by ●March 27, 20092009-03-27
Anders Lindgren wrote:
> Anders Lindgren wrote:
> > stefandk63 wrote:
> > > I make first attempts to work with FG4616, moving assembler code from
> > F449.
> > > Linker gives me 1 warning:
> > > Warning[w29]: Parts of segment DATA16_N are initialized (as in module
> > > Mymain), even though it is of type DATA (and
> > > thus not promable)
> > > I think this is due 'holes' between byte and word aligned zones.
> >
> > Hi Stefan!
> >
> > I haven't seen this warning being triggered by something like that -- if
> > you can you make a small example that triggers the warning, I could take
> > a look at it.
> >
> > -- Anders Lindgren, IAR Systems
>
> Hi Stefan!
>
> I took a look at the code you sent me.
>
> It appears as the cause of the problem is the "EVEN" directive. When it
> aligns code, it emits a physical byte even though it is in a DATA segment.
>
> As a work-around you can either align the code manually, or you can
> start a new segment part for each variable that must be aligned. One
> advantage of the latter is that it would allow the linker to throw out
> unused variables.
>
> In other words, you can write:
>
> RSEG DATA16_N:DATA:REORDER:NOROOT(1)
> foo: DS 2
>
> The "1" in the RSEG directive says that the segment part should be
> aligned at an even 2^1 = 2 bytes.
After consulting with a colleague, I realized that EVEN is designed to
emit a byte. However, we provide the "ALIGNRAM 1" directive to align a
data segment.
-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.
> Anders Lindgren wrote:
> > stefandk63 wrote:
> > > I make first attempts to work with FG4616, moving assembler code from
> > F449.
> > > Linker gives me 1 warning:
> > > Warning[w29]: Parts of segment DATA16_N are initialized (as in module
> > > Mymain), even though it is of type DATA (and
> > > thus not promable)
> > > I think this is due 'holes' between byte and word aligned zones.
> >
> > Hi Stefan!
> >
> > I haven't seen this warning being triggered by something like that -- if
> > you can you make a small example that triggers the warning, I could take
> > a look at it.
> >
> > -- Anders Lindgren, IAR Systems
>
> Hi Stefan!
>
> I took a look at the code you sent me.
>
> It appears as the cause of the problem is the "EVEN" directive. When it
> aligns code, it emits a physical byte even though it is in a DATA segment.
>
> As a work-around you can either align the code manually, or you can
> start a new segment part for each variable that must be aligned. One
> advantage of the latter is that it would allow the linker to throw out
> unused variables.
>
> In other words, you can write:
>
> RSEG DATA16_N:DATA:REORDER:NOROOT(1)
> foo: DS 2
>
> The "1" in the RSEG directive says that the segment part should be
> aligned at an even 2^1 = 2 bytes.
After consulting with a colleague, I realized that EVEN is designed to
emit a byte. However, we provide the "ALIGNRAM 1" directive to align a
data segment.
-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.
Reply by ●March 27, 20092009-03-27
On Fri, 27 Mar 2009 17:03:01 +0100, you wrote:
>Anders Lindgren wrote:
>> Anders Lindgren wrote:
>> > stefandk63 wrote:
>> > > I make first attempts to work with FG4616, moving assembler code from
>> > F449.
>> > > Linker gives me 1 warning:
>> > > Warning[w29]: Parts of segment DATA16_N are initialized (as in module
>> > > Mymain), even though it is of type DATA (and
>> > > thus not promable)
>> > > I think this is due 'holes' between byte and word aligned zones.
>> >
>> > Hi Stefan!
>> >
>> > I haven't seen this warning being triggered by something like that -- if
>> > you can you make a small example that triggers the warning, I could take
>> > a look at it.
>> >
>> > -- Anders Lindgren, IAR Systems
>>
>> Hi Stefan!
>>
>> I took a look at the code you sent me.
>>
>> It appears as the cause of the problem is the "EVEN" directive. When it
>> aligns code, it emits a physical byte even though it is in a DATA segment.
>>
>> As a work-around you can either align the code manually, or you can
>> start a new segment part for each variable that must be aligned. One
>> advantage of the latter is that it would allow the linker to throw out
>> unused variables.
>>
>> In other words, you can write:
>>
>> RSEG DATA16_N:DATA:REORDER:NOROOT(1)
>> foo: DS 2
>>
>> The "1" in the RSEG directive says that the segment part should be
>> aligned at an even 2^1 = 2 bytes.
>
>After consulting with a colleague, I realized that EVEN is designed to
>emit a byte. However, we provide the "ALIGNRAM 1" directive to align a
>data segment.
Why was it designed that way?
Jon
>Anders Lindgren wrote:
>> Anders Lindgren wrote:
>> > stefandk63 wrote:
>> > > I make first attempts to work with FG4616, moving assembler code from
>> > F449.
>> > > Linker gives me 1 warning:
>> > > Warning[w29]: Parts of segment DATA16_N are initialized (as in module
>> > > Mymain), even though it is of type DATA (and
>> > > thus not promable)
>> > > I think this is due 'holes' between byte and word aligned zones.
>> >
>> > Hi Stefan!
>> >
>> > I haven't seen this warning being triggered by something like that -- if
>> > you can you make a small example that triggers the warning, I could take
>> > a look at it.
>> >
>> > -- Anders Lindgren, IAR Systems
>>
>> Hi Stefan!
>>
>> I took a look at the code you sent me.
>>
>> It appears as the cause of the problem is the "EVEN" directive. When it
>> aligns code, it emits a physical byte even though it is in a DATA segment.
>>
>> As a work-around you can either align the code manually, or you can
>> start a new segment part for each variable that must be aligned. One
>> advantage of the latter is that it would allow the linker to throw out
>> unused variables.
>>
>> In other words, you can write:
>>
>> RSEG DATA16_N:DATA:REORDER:NOROOT(1)
>> foo: DS 2
>>
>> The "1" in the RSEG directive says that the segment part should be
>> aligned at an even 2^1 = 2 bytes.
>
>After consulting with a colleague, I realized that EVEN is designed to
>emit a byte. However, we provide the "ALIGNRAM 1" directive to align a
>data segment.
Why was it designed that way?
Jon
Reply by ●March 30, 20092009-03-30
Jon Kirwan wrote:
> >After consulting with a colleague, I realized that EVEN is designed to
> >emit a byte. However, we provide the "ALIGNRAM 1" directive to align a
> >data segment.
>
> Why was it designed that way?
No idea, this was done long before my time (and I've been here for more
than ten years). Unfortunately, it's not easy to change something like
this, as there might be users out there that rely on the current behavior.
-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.
> >After consulting with a colleague, I realized that EVEN is designed to
> >emit a byte. However, we provide the "ALIGNRAM 1" directive to align a
> >data segment.
>
> Why was it designed that way?
No idea, this was done long before my time (and I've been here for more
than ten years). Unfortunately, it's not easy to change something like
this, as there might be users out there that rely on the current behavior.
-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.
Reply by ●March 30, 20092009-03-30
On Mon, 30 Mar 2009 11:07:29 +0200, you wrote:
>Jon Kirwan wrote:
>> >After consulting with a colleague, I realized that EVEN is designed to
>> >emit a byte. However, we provide the "ALIGNRAM 1" directive to align a
>> >data segment.
>>
>> Why was it designed that way?
>
>No idea, this was done long before my time (and I've been here for more
>than ten years). Unfortunately, it's not easy to change something like
>this, as there might be users out there that rely on the current behavior.
>
> -- Anders Lindgren, IAR Systems
I take it your imagination, like mine, has difficulty even coming up
with a good reason. Especially since EVEN has been a pseudo-op in
assemblers I've used going back at least to the early 1970's. And
without emitting a byte to do it. If I had to guess, I'd say there
was a flaw in the linker of the day and this was patched in by way of
making things work. Now you pay the price for the defect by making it
a standard requirement as people may have come to rely upon the odd
behavior.
Thanks for the short note about it. You'd made me curious, as I was
sitting here struggling to gather a reason why and all you'd said was
that it was designed that way. Which left me wondering. Now, at
least, I know that even you don't know why. Which puts me at some
ease, in that at least I'm not necessarily any more ignorant than some
others.
Thanks,
Jon
>Jon Kirwan wrote:
>> >After consulting with a colleague, I realized that EVEN is designed to
>> >emit a byte. However, we provide the "ALIGNRAM 1" directive to align a
>> >data segment.
>>
>> Why was it designed that way?
>
>No idea, this was done long before my time (and I've been here for more
>than ten years). Unfortunately, it's not easy to change something like
>this, as there might be users out there that rely on the current behavior.
>
> -- Anders Lindgren, IAR Systems
I take it your imagination, like mine, has difficulty even coming up
with a good reason. Especially since EVEN has been a pseudo-op in
assemblers I've used going back at least to the early 1970's. And
without emitting a byte to do it. If I had to guess, I'd say there
was a flaw in the linker of the day and this was patched in by way of
making things work. Now you pay the price for the defect by making it
a standard requirement as people may have come to rely upon the odd
behavior.
Thanks for the short note about it. You'd made me curious, as I was
sitting here struggling to gather a reason why and all you'd said was
that it was designed that way. Which left me wondering. Now, at
least, I know that even you don't know why. Which puts me at some
ease, in that at least I'm not necessarily any more ignorant than some
others.
Thanks,
Jon
