LPC2119 In_Application Programming

-I'm working with the LPC2119, and need to program the Flash via IAP,
it's kind of an upgrade to the flash code.
-I'm using the Interworking feature.
-I start making an executable region for the flash programming in RAM,
so i can erase the flash and still working, BUT in someway, the code
in the RAM has references in part of the ROM, they are the veneers,
and as i erased the flash, i can't finish the programming because
there's no end.

Can anybody help me with this?

"Ricardo Lozano" <lozanet@yahoo.com> wrote in message
news:feb24846.0404131229.4376da86@posting.google.com...
> -I'm working with the LPC2119, and need to program the Flash via IAP,
> it's kind of an upgrade to the flash code.
> -I'm using the Interworking feature.
> -I start making an executable region for the flash programming in RAM,
> so i can erase the flash and still working, BUT in someway, the code
> in the RAM has references in part of the ROM, they are the veneers,
> and as i erased the flash, i can't finish the programming because
> there's no end.
>
> Can anybody help me with this?

If you're using scatterloading in ARM tools, put *(Veneer$$Code)  in your
RAM execution region - the linker will place them there if there is enough
space.

Peter.

> If you're using scatterloading in ARM tools, put *(Veneer$$Code)  in your
> RAM execution region - the linker will place them there if there is enough
> space.

Oops... AND the veneers have to be within the calling range of the code that
is making an interworked function call: +/- 4MByte for Thumb code,
+/-32MByte for ARM code, I believe.

"CodeSprite" <pmaloy@codesprite.com> wrote in message news:<407c50e2$0$79436$812600b3@news.nntpaccess.com>...
> > If you're using scatterloading in ARM tools, put *(Veneer$$Code)  in your
> > RAM execution region - the linker will place them there if there is enough
> > space.
> 
> Oops... AND the veneers have to be within the calling range of the code that
> is making an interworked function call: +/- 4MByte for Thumb code,
> +/-32MByte for ARM code, I believe.

Mmmmh, i don't understand the second part, and i have warnings loading
some veneers to the image.
Can you explain what to do?

"Ricardo Lozano" <lozanet@yahoo.com> wrote in message
news:feb24846.0404140538.39c7d340@posting.google.com...
> "CodeSprite" <pmaloy@codesprite.com> wrote in message
news:<407c50e2$0$79436$812600b3@news.nntpaccess.com>...
> > > If you're using scatterloading in ARM tools, put *(Veneer$$Code)  in
your
> > > RAM execution region - the linker will place them there if there is
enough
> > > space.
> >
> > Oops... AND the veneers have to be within the calling range of the code
that
> > is making an interworked function call: +/- 4MByte for Thumb code,
> > +/-32MByte for ARM code, I believe.
>
> Mmmmh, i don't understand the second part, and i have warnings loading
> some veneers to the image.
> Can you explain what to do?

Ok I'll try...

The ARM embeds the destination of a branch or branch with link (function
call) withing a 32-bit instruction. It also has to use 4 bits of that
instruction to represent the conditional execution code (ie branch if equal,
branch if carry set), and a further few bits are reserved just to say that
this instruction is a branch or branch-link.

This means that there are less than 32 bits available to represent the
destination address. We don't have to store the bottom 2 bits, because we
know the destination address is 32-bit aligned, but that still restricts the
address range available. So those cunning people at ARM have done is to
encode the address as an offset from the current program counter (which is
actually 8 bytes further on from the branch, since the core is busy fetching
the instruction two instructions further down the code at the time it is
executing the Branch).

The upshot of this is that the destination for the branch has to be within
32MBytes of the program counter. This isn't a huge problem - the linker will
insert a "long branch veneer" if we stray too far.The veneer will allow us
to reach a destination anywhere in the 4GByte address space - at the cost of
a short additional delay (another reason not to allow your hardware designer
to specify the memory map without thinking about the impact on software).

Now, with the *(Veneer$$Code) directive, we're telling the linker to put all
the veneers into RAM - which may be out of range from the Flash code. The
linker will keep any out of range veneers close to the code that making the
call, but will issue a warning.

When you're programming the flash, I'm sure that you're not calling any
functions that are sitting in flash - so perhaps the *(Veneer$$Code)
directive can be modified to move only the flash program code veneers into
RAM:

flash_thumb.o (Veneer$$Code)
flash_arm.o (Veneer$$Code)

All other veneers should then stay in Flash and the warnings should
disappear.

I dunno... haven't tried it, but it seems logical...

Peter.