Hallo!

This is a question for folks used to IAR compiler.

Something a bit strange is happening with my compiler. I'm using IAR
Embedded Workbench V2.10A for EW430.

My program calls some assembly routine during the initialization of the
microcontroller. After a branch instruction, the "call stack" window
starts to show nonsense information.
In place of the root of the stack I see [exit + 0x18b8], then a continous call
to the same function (256 calls, by the way, it's not a recursive function
so it's very hard that it calls itself) and then the right "call
stack" with the right main and the function that are supposed to be called.
I've found an explaination for this behaviour. After that
"branch" instruction, the compiler starts to believe that the
beginning of the stack is at memory location 0xc00, so the following 0x200 bytes
(that are filled with 0x3ff) are mistaken as records of call to the function at
location 0x3fff (in fact the name of the function called in the "call
stack" window is the name of the function at 0x3fff memory location).
Even if I see this wrong information in the "call stack" window, if I
look at the "memory" window and at the SP value everything is ok, so I
suppose that something is going wrong in the debugger software but my firmware
is ok. But I must be sure of this. 

Another strange thing is that this malfunction happens only when some lines of
code are compiled. If I don't compile these lines (adding "//"
before them) this malfunction disappears. This code is not executed before the
malfunction, so I can't understand how it can affect the debugger.

Can you try to explain what happens and how i can avoid this?

Best Regards

Vito Russo

Hi!

> This is a question for folks used to IAR compiler.
>
> Something a bit strange is happening with my compiler. I'm using IAR
> Embedded Workbench V2.10A for EW430.
>
> My program calls some assembly routine during the initialization of
> the microcontroller. After a branch instruction, the "call stack"
> window starts to show nonsense information.  In place of the root of
> the stack I see [exit + 0x18b8], then a continous call to the same
> function (256 calls, by the way, it's not a recursive function so
> it's very hard that it calls itself) and then the right "call
stack"
> with the right main and the function that are supposed to be called.
> I've found an explaination for this behaviour. After that
"branch"
> instruction, the compiler starts to believe that the beginning of
> the stack is at memory location 0xc00, so the following 0x200 bytes
> (that are filled with 0x3ff) are mistaken as records of call to the
> function at location 0x3fff (in fact the name of the function called
> in the "call stack" window is the name of the function at 0x3fff
> memory location).  Even if I see this wrong information in the "call
> stack" window, if I look at the "memory" window and at the
SP value
> everything is ok, so I suppose that something is going wrong in the
> debugger software but my firmware is ok. But I must be sure of this.

The debugger uses so-called "call frame information" to determine the
content of the call stack window.  This information is provided by the
compiler or assembler, so if there is a problem it's probably not
located in the debugger.

For assembler routines, by default there is no call stack information,
so whenever you are debugging an assembler routine the call stack
window should contain only the current line.

However, it's possible to describe the call stack using the assembler
"CFI" directive.  It's syntax is somewhat complex so it's a
lot of
work in order to just get the call stack window up and running.


Unfortunately, it's a but unclear from your posting whether the
problem occured inside the assmebler routine, or in C code that called
the assembler routines.


If this happend in the C code after you have called the assembler
routines then your code could very well be broken.  The behaviour you
describe indicates that the return adress for the C routine is not
where the code expects it to be.  This can happend if your routine
doesn't restore the SP to its original value, or if it overwritts
parts of the stack.

If it happend when you are single-stepping your assembler code then my
guess is that it contains CFI directives that no longer are
up-to-date, so that the debugger looks in the wrong location for the
return address.  The simplest solution is to delete the CFI
directives, ensuring that they are correct is another alternative.


Of course, the problem could lie elsewhere, but the two cases above
seems like the most likely candidates.

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

Hallo Anders.

Thank you for your interest. I've looked at the CFI documentation and it
looks really a lot of work to setup a working call stack window, so I want
to try other way before.

I've additional information about my problem now (and maybe some old
information are now obsolete).

The call stack window malfunction seems related to the code size of my
program.

I've taken an old (well 3 days ago, not so ancient) version of my program.
In that version the call stack window was correctly working.
I started adding "nops" (with the directive __no_operation() ) at the
beginning of my code. I've dicovered that the call stack window stops
working when the code size reaches 17972 bytes, while it works for code size
of 17970 or less.

I also try to explain when the malfunction happens.
In the beginning of my program there's a little assembler routine that
chooses if the bootloader code or the main code are going to be executed.
At the end of this routine there's a branch instruction that jumps to the
bootloader code or to the main code. Both the bootloader code and the main
code are written in C, so the branch jumps to a label that is the name of a
C function.
Everything works ok before the branch (in the call stack window I read
something like [lastlabel + offset], which shuold be normal during cstartup
and other assembly routines). I've seen this putting a breakpoint on the
branch instruction.
After the branch (but keep in mind, this happens only when the size of
compiled code is 17972 or higher) the call stack window shows wrong data.
I've seen this putting a breakpoint on the first instruction to be executed
after the branch in the disassembly window.

I hope that with this new information you can give me an hint.. however
thanks anyway.

Regards

Vito Russo

----- Original Message -----
From: "Anders Lindgren" <Anders.lindgren@Ande...>
To: <msp430@msp4...>
Sent: Monday, January 10, 2005 12:27 PM
Subject: Re: [msp430] Debugger Bug?


>
>
> Hi!
>
> > This is a question for folks used to IAR compiler.
> >
> > Something a bit strange is happening with my compiler. I'm using
IAR
> > Embedded Workbench V2.10A for EW430.
> >
> > My program calls some assembly routine during the initialization of
> > the microcontroller. After a branch instruction, the "call
stack"
> > window starts to show nonsense information.  In place of the root of
> > the stack I see [exit + 0x18b8], then a continous call to the same
> > function (256 calls, by the way, it's not a recursive function so
> > it's very hard that it calls itself) and then the right
"call stack"
> > with the right main and the function that are supposed to be called.
> > I've found an explaination for this behaviour. After that
"branch"
> > instruction, the compiler starts to believe that the beginning of
> > the stack is at memory location 0xc00, so the following 0x200 bytes
> > (that are filled with 0x3ff) are mistaken as records of call to the
> > function at location 0x3fff (in fact the name of the function called
> > in the "call stack" window is the name of the function at
0x3fff
> > memory location).  Even if I see this wrong information in the
"call
> > stack" window, if I look at the "memory" window and at
the SP value
> > everything is ok, so I suppose that something is going wrong in the
> > debugger software but my firmware is ok. But I must be sure of this.
>
> The debugger uses so-called "call frame information" to determine
the
> content of the call stack window.  This information is provided by the
> compiler or assembler, so if there is a problem it's probably not
> located in the debugger.
>
> For assembler routines, by default there is no call stack information,
> so whenever you are debugging an assembler routine the call stack
> window should contain only the current line.
>
> However, it's possible to describe the call stack using the assembler
> "CFI" directive.  It's syntax is somewhat complex so
it's a lot of
> work in order to just get the call stack window up and running.
>
>
> Unfortunately, it's a but unclear from your posting whether the
> problem occured inside the assmebler routine, or in C code that called
> the assembler routines.
>
>
> If this happend in the C code after you have called the assembler
> routines then your code could very well be broken.  The behaviour you
> describe indicates that the return adress for the C routine is not
> where the code expects it to be.  This can happend if your routine
> doesn't restore the SP to its original value, or if it overwritts
> parts of the stack.
>
> If it happend when you are single-stepping your assembler code then my
> guess is that it contains CFI directives that no longer are
> up-to-date, so that the debugger looks in the wrong location for the
> return address.  The simplest solution is to delete the CFI
> directives, ensuring that they are correct is another alternative.
>
>
> Of course, the problem could lie elsewhere, but the two cases above
> seems like the most likely candidates.
>
>     -- Anders Lindgren, IAR Systems
> --
> Disclaimer: Opinions expressed in this posting are strictly my own and
> not necessarily those of my employer.
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

> Thank you for your interest. I've looked at
the CFI documentation and it
> looks really a lot of work to setup a working call stack window, so I want
> to try other way before.
>
> I've additional information about my problem now (and maybe some old
> information are now obsolete).
>
> The call stack window malfunction seems related to the code size of my
> program.
>
> I've taken an old (well 3 days ago, not so ancient) version of my
program.
> In that version the call stack window was correctly working.
> I started adding "nops" (with the directive __no_operation() ) at
the
> beginning of my code. I've dicovered that the call stack window stops
> working when the code size reaches 17972 bytes, while it works for code
size
> of 17970 or less.
>
> I also try to explain when the malfunction happens.
> In the beginning of my program there's a little assembler routine that
> chooses if the bootloader code or the main code are going to be executed.
> At the end of this routine there's a branch instruction that jumps to
the
> bootloader code or to the main code. Both the bootloader code and the main
> code are written in C, so the branch jumps to a label that is the name of a
> C function.
> Everything works ok before the branch (in the call stack window I read
> something like [lastlabel + offset], which shuold be normal during cstartup
> and other assembly routines). I've seen this putting a breakpoint on
the
> branch instruction.
> After the branch (but keep in mind, this happens only when the size of
> compiled code is 17972 or higher) the call stack window shows wrong data.
> I've seen this putting a breakpoint on the first instruction to be
executed
> after the branch in the disassembly window.
>
> I hope that with this new information you can give me an hint.. however
> thanks anyway.

Hi Vito!

It sounds really strange that the code size would influence the
behaviour of the call stack window.

I can't speculate in the cause, but if you can create a simple example
I can take look at it.  (We can take it off the list and post a
summary here when we find the cause.)

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

Hallo Anders.

Sorry for my very late reply.

The first part of the letter is a chronicle of what I've done. I've
done
some "unconventional" actions in my code, so I think that they are the
reason of the debugger malfunction.
In the last part of the letter I have a new question about the EWB. I'm not
sure the best thing to do is to fix thsi problem with the debugger, maybe
it's better to choose a different structure for my software.

Well, it sounds strange but is it true. I've disable some part of my
firmware to keep code size under the 17972 bytes while I was developing the
new routines, so I was able to debug without problems.
When I completed the new routines I re-enabled all the code and I saw that
the firmware works well even if the call stack window shows wrong
information. By the way, it is possible to debug even with the wrong
information in the call stack window, because the last calls displayed are
always right (looking at the stack window it is also possible to understand
that the microcontroller is working correctly, because the wrong calls in
the stack window are located at addresses higher than 0xA00, so out of the
RAM).

I have an idea about the explaination for this behaviour.
I've developed a boot-loader routine. This routine is the only part of the
code that can't be modified by the boot-loading process (it can't
delet
itself).
To do this I've placed it in a "protected" memory segment.
I've written it
in C.
I've discovered that even if I tell to the comiler to place a function in a
memory segment, declaring it as function() @ "MemorySegment", the
function
isn't completely placed in that memory segment.
In fact, at the end of the function, the program jumps to some labels called
"?epilogues" where all registers used by the routine are
re-established to
their original value.
This was a problem, because when a different code is compiled the epilogues
are placed in a different place, so after the first update the bootloader
routine jumps to the wrong place.
So I've copied the "?Epilogues" block in a assembly file and
I've placed
them in the protected segment. I've seen that doing this way the
compiler\linker doesn't add its own "?Epilogues" and uses the
ones defined
in my assembly file /even for the main code, not only for the bootloader).

I've done the same thing for the "memset" function (I need to
choose the
right SIZE_OF_DATA16_Z, because it is different for the main code and the
bootloader).

And I placed the CSTARTUP segment inside the protected memory segment.

I think that these are all non conventional actions and maybe this is why
the debugger shows wrong data.

Well, I don't like this structure, I've written it a long time ago and
I've
kept it because I haven't the time to modify it (by the way it is not
compatible with the latest releases of EWB too. I'm using version V2.10A
and
my code doesn't work with the newer versions i've received from IAR,
they
told me that the cstartup mechanism is changed).

So here's my new question.

I think it should be better to build two separe projects, one for the
bootloader and one for the main code and then link them together. I mean
that each project should have its own "?epilogues" (if they still
exist),
math library, memset, etc.
Is there a way to do this?

Best Regards

Vito Russo

----- Original Message -----
From: "Anders Lindgren" <Anders.lindgren@Ande...>
To: <msp430@msp4...>
Sent: Thursday, January 13, 2005 4:34 PM
Subject: Re: [msp430] Debugger Bug?


>
>
> > Thank you for your interest. I've looked at the CFI documentation
and it
> > looks really a lot of work to setup a working call stack window, so I
want
> > to try other way before.
> >
> > I've additional information about my problem now (and maybe some
old
> > information are now obsolete).
> >
> > The call stack window malfunction seems related to the code size of my
> > program.
> >
> > I've taken an old (well 3 days ago, not so ancient) version of my
program.
> > In that version the call stack window was
correctly working.
> > I started adding "nops" (with the directive __no_operation()
) at the
> > beginning of my code. I've dicovered that the call stack window
stops
> > working when the code size reaches 17972 bytes, while it works for
code
size
> > of 17970 or less.
> >
> > I also try to explain when the malfunction happens.
> > In the beginning of my program there's a little assembler routine
that
> > chooses if the bootloader code or the main code are going to be
executed.
> > At the end of this routine there's a
branch instruction that jumps to
the
> > bootloader code or to the main code. Both the
bootloader code and the
main
> > code are written in C, so the branch jumps to
a label that is the name
of a
> > C function.
> > Everything works ok before the branch (in the call stack window I read
> > something like [lastlabel + offset], which shuold be normal during
cstartup
> > and other assembly routines). I've seen
this putting a breakpoint on the
> > branch instruction.
> > After the branch (but keep in mind, this happens only when the size of
> > compiled code is 17972 or higher) the call stack window shows wrong
data.
> > I've seen this putting a breakpoint on
the first instruction to be
executed
> > after the branch in the disassembly window.
> >
> > I hope that with this new information you can give me an hint..
however
> > thanks anyway.
>
> Hi Vito!
>
> It sounds really strange that the code size would influence the
> behaviour of the call stack window.
>
> I can't speculate in the cause, but if you can create a simple example
> I can take look at it.  (We can take it off the list and post a
> summary here when we find the cause.)
>
>     -- Anders Lindgren, IAR Systems
> --
> Disclaimer: Opinions expressed in this posting are strictly my own and
> not necessarily those of my employer.
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>

Hi Vito!

> Sorry for my very late reply.
>
> The first part of the letter is a chronicle of what I've done.
I've done
> some "unconventional" actions in my code, so I think that they
are the
> reason of the debugger malfunction.


> Well, it sounds strange but is it true. I've
disable some part of my
> firmware to keep code size under the 17972 bytes while I was developing the
> new routines, so I was able to debug without problems.
> When I completed the new routines I re-enabled all the code and I saw that
> the firmware works well even if the call stack window shows wrong
> information. By the way, it is possible to debug even with the wrong
> information in the call stack window, because the last calls displayed are
> always right (looking at the stack window it is also possible to understand
> that the microcontroller is working correctly, because the wrong calls in
> the stack window are located at addresses higher than 0xA00, so out of the
> RAM).

My guess is still that you somehow have changed the stack pointer or
the content of the stack.  I'm curious about one thing -- what would
happend if you let the rotine with the broken backtrace actually
return?  My guess is that it would end up right there where the call
stack window says it would.

This would explain why the call stack window would change when the
code size grows.  If this location is somewhere there is code with
backtrace, the debugger will try to find its parent etc. etc.  On the
other hand, if you land somewhere without backtrace it simply stops.
(Oh, well, this was simply an explanation why the symptoms differed in
different situations.  I didn't try to solve the problem.)

Over to the problem itself -- you yourself have to take a look at the
code and what actually happends with the stack and the stack pointer
when the stack goes wild.  My guess is that it's ok if the last
function in the call stack that looks ok will never return (and it if
has nothing stored on the stack).


> Well, I don't like this structure, I've
written it a long time ago and I've
> kept it because I haven't the time to modify it (by the way it is not
> compatible with the latest releases of EWB too. I'm using version
V2.10A and
> my code doesn't work with the newer versions i've received from
IAR, they
> told me that the cstartup mechanism is changed).

The mechanims hasn't changed that much at all.  You can probably spot
the differences between an old and a new cstartup file.


> I think it should be better to build two separe
projects, one for the
> bootloader and one for the main code and then link them together. I mean
> that each project should have its own "?epilogues" (if they still
exist),
> math library, memset, etc.
> Is there a way to do this?

Whay you can do is to have two different projects all together.  That
means that you will get two different end-result files that you have
to download separately.

The problem is that you can't really exchange information between the
two projects so you have to decide on some handshaking mechanism, for
example hardwire a memory location where one of the applications is
placed.

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

Hi Anders,

sorry again for my late reply.

I've tried to force to return the function on top of the call stack and in
effect the PC starts running wild and free trough the memory... Luckily this
function never returns, so the code should be ok (this is the main point).
However I've placed a breakpoint on the "wrong" function of the
call stack
and the PC didn't stop there.

Now I'm building the bootloader and the main code as separate projects.
Doing this way I can avoid every cstartup modification and function
redefinition. I'll tell you what happens when I finish it (but wait a
little
since I'm doing it in my "spare" time). I bet that the 17972
bytes "bug"
will disappear, :-)

Thank you very much for your help.

Greetings from Venice.

Vito Russo

----- Original Message ----- 
From: "Anders Lindgren" <Anders.lindgren@Ande...>
To: <msp430@msp4...>
Sent: Friday, January 28, 2005 1:24 PM
Subject: Re: [msp430] Debugger Bug?


>
>
> Hi Vito!
>
> > Sorry for my very late reply.
> >
> > The first part of the letter is a chronicle of what I've done.
I've done
> > some "unconventional" actions in my code, so I think that
they are the
> > reason of the debugger malfunction.
>
>
> > Well, it sounds strange but is it true. I've disable some part of
my
> > firmware to keep code size under the 17972 bytes while I was
developing
the
> > new routines, so I was able to debug without
problems.
> > When I completed the new routines I re-enabled all the code and I saw
that
> > the firmware works well even if the call
stack window shows wrong
> > information. By the way, it is possible to debug even with the wrong
> > information in the call stack window, because the last calls displayed
are
> > always right (looking at the stack window it
is also possible to
understand
> > that the microcontroller is working
correctly, because the wrong calls
in
> > the stack window are located at addresses
higher than 0xA00, so out of
the
> > RAM).
>
> My guess is still that you somehow have changed the stack pointer or
> the content of the stack.  I'm curious about one thing -- what would
> happend if you let the rotine with the broken backtrace actually
> return?  My guess is that it would end up right there where the call
> stack window says it would.
>
> This would explain why the call stack window would change when the
> code size grows.  If this location is somewhere there is code with
> backtrace, the debugger will try to find its parent etc. etc.  On the
> other hand, if you land somewhere without backtrace it simply stops.
> (Oh, well, this was simply an explanation why the symptoms differed in
> different situations.  I didn't try to solve the problem.)
>
> Over to the problem itself -- you yourself have to take a look at the
> code and what actually happends with the stack and the stack pointer
> when the stack goes wild.  My guess is that it's ok if the last
> function in the call stack that looks ok will never return (and it if
> has nothing stored on the stack).
>
>
> > Well, I don't like this structure, I've written it a long
time ago and
I've
> > kept it because I haven't the time to
modify it (by the way it is not
> > compatible with the latest releases of EWB too. I'm using version
V2.10A
and
> > my code doesn't work with the newer
versions i've received from IAR,
they
> > told me that the cstartup mechanism is
changed).
>
> The mechanims hasn't changed that much at all.  You can probably spot
> the differences between an old and a new cstartup file.
>
>
> > I think it should be better to build two separe projects, one for the
> > bootloader and one for the main code and then link them together. I
mean
> > that each project should have its own "?epilogues" (if they
still
exist),
> > math library, memset, etc.
> > Is there a way to do this?
>
> Whay you can do is to have two different projects all together.  That
> means that you will get two different end-result files that you have
> to download separately.
>
> The problem is that you can't really exchange information between the
> two projects so you have to decide on some handshaking mechanism, for
> example hardwire a memory location where one of the applications is
> placed.
>
>     -- Anders Lindgren, IAR Systems
> -- 
> Disclaimer: Opinions expressed in this posting are strictly my own and
> not necessarily those of my employer.
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>

Hallo!

The conversion to the new bootloader structure took less time than I
expected.
It works very good.

Now I download the bootloader and the main code as separated programs.
There's only a "wired" (I mean placed at a given absolute
address)
instruction that I use to route the PC to the bootloader or the main program
when the system starts up (Ops, this is not completely true, also the
interrupt service routine are "wired", because it's to risky
trying to
modify them and the reset vector).

The bug related to the code size disappeared. I expected this because now
I'm using the EW430 in a more standard way, the only modification I made
are
redefinition of memory segmnets, but I use the default cstartup file, not
the one costomized by me.

I've also successfully migrated to the last version of EW430 that IAR sent
to me (3.10) without problems.

Thank you very much again.

Vito

----- Original Message ----- 
From: "Vito Russo" <vrusso@vrus...>
To: <msp430@msp4...>
Sent: Tuesday, February 08, 2005 1:31 PM
Subject: Re: [msp430] Debugger Bug?


>
> Hi Anders,
>
> sorry again for my late reply.
>
> I've tried to force to return the function on top of the call stack
and in
> effect the PC starts running wild and free trough the memory... Luckily
this
> function never returns, so the code should be ok
(this is the main point).
> However I've placed a breakpoint on the "wrong" function of
the call stack
> and the PC didn't stop there.
>
> Now I'm building the bootloader and the main code as separate
projects.
> Doing this way I can avoid every cstartup modification and function
> redefinition. I'll tell you what happens when I finish it (but wait a
little
> since I'm doing it in my "spare"
time). I bet that the 17972 bytes "bug"
> will disappear, :-)
>
> Thank you very much for your help.
>
> Greetings from Venice.
>
> Vito Russo
>
> ----- Original Message ----- 
> From: "Anders Lindgren" <Anders.lindgren@Ande...>
> To: <msp430@msp4...>
> Sent: Friday, January 28, 2005 1:24 PM
> Subject: Re: [msp430] Debugger Bug?
>
>
> >
> >
> > Hi Vito!
> >
> > > Sorry for my very late reply.
> > >
> > > The first part of the letter is a chronicle of what I've
done. I've
done
> > > some "unconventional" actions
in my code, so I think that they are the
> > > reason of the debugger malfunction.
> >
> >
> > > Well, it sounds strange but is it true. I've disable some
part of my
> > > firmware to keep code size under the 17972 bytes while I was
developing
> the
> > > new routines, so I was able to debug without problems.
> > > When I completed the new routines I re-enabled all the code and I
saw
> that
> > > the firmware works well even if the call stack window shows wrong
> > > information. By the way, it is possible to debug even with the
wrong
> > > information in the call stack window, because the last calls
displayed
> are
> > > always right (looking at the stack window it is also possible to
> understand
> > > that the microcontroller is working correctly, because the wrong
calls
> in
> > > the stack window are located at addresses higher than 0xA00, so
out of
> the
> > > RAM).
> >
> > My guess is still that you somehow have changed the stack pointer or
> > the content of the stack.  I'm curious about one thing -- what
would
> > happend if you let the rotine with the broken backtrace actually
> > return?  My guess is that it would end up right there where the call
> > stack window says it would.
> >
> > This would explain why the call stack window would change when the
> > code size grows.  If this location is somewhere there is code with
> > backtrace, the debugger will try to find its parent etc. etc.  On the
> > other hand, if you land somewhere without backtrace it simply stops.
> > (Oh, well, this was simply an explanation why the symptoms differed in
> > different situations.  I didn't try to solve the problem.)
> >
> > Over to the problem itself -- you yourself have to take a look at the
> > code and what actually happends with the stack and the stack pointer
> > when the stack goes wild.  My guess is that it's ok if the last
> > function in the call stack that looks ok will never return (and it if
> > has nothing stored on the stack).
> >
> >
> > > Well, I don't like this structure, I've written it a
long time ago and
> I've
> > > kept it because I haven't the time to modify it (by the way
it is not
> > > compatible with the latest releases of EWB too. I'm using
version
V2.10A
> and
> > > my code doesn't work with the newer versions i've
received from IAR,
> they
> > > told me that the cstartup mechanism is changed).
> >
> > The mechanims hasn't changed that much at all.  You can probably
spot
> > the differences between an old and a new cstartup file.
> >
> >
> > > I think it should be better to build two separe projects, one for
the
> > > bootloader and one for the main code and then link them together.
I
mean
> > > that each project should have its own
"?epilogues" (if they still
> exist),
> > > math library, memset, etc.
> > > Is there a way to do this?
> >
> > Whay you can do is to have two different projects all together.  That
> > means that you will get two different end-result files that you have
> > to download separately.
> >
> > The problem is that you can't really exchange information between
the
> > two projects so you have to decide on some handshaking mechanism, for
> > example hardwire a memory location where one of the applications is
> > placed.
> >
> >     -- Anders Lindgren, IAR Systems
> > -- 
> > Disclaimer: Opinions expressed in this posting are strictly my own and
> > not necessarily those of my employer.
> >
> >
> > .
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
>
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>