Karl, I'm an LPC newbie so please excuse my silly question but, why
not just...?
void (*CallIAP)(unsigned int *cmd, unsigned int *resp) = 0x7ffffff1;
void My Func()
{
.
.
CallIAP(cmd, resp);
.
.
}
What does the assembler routine you wrote do different from this?
Guille
--- In lpc2000@yahoogroups.com, "Karl Olsen" <kro@p...> wrote:
>
> ---- Original Message ----
> From: "Tom Walsh" <tom@o...>
> To: <lpc2000@yahoogroups.com>
> Sent: Friday, October 28, 2005 7:52 PM
> Subject: Re: [lpc2000] Re: LPC2138FBD64 - not possible to run from
> Flash and use IAP?
>
> > Karl Olsen wrote:
> >
> >> Most probably, the whole flash is unreadable during programming,
and
> >> there is no secret RAM. The User Manual says that the IAP
commands
> >> for write/erase use the top 32 bytes of RAM for execution, and
that
> >> you shouldn't use these bytes if you use write/erase IAP calls in
> >> your program. 32 bytes should be enough for some Thumb code that
> >> starts the write/erase, waits for it to finish, and returns to
the
> >> again accessible IAP code in flash.
> >
> > Yeah, I did the same with an 80C188 design + 28F010 Flash. I put
a
> > small routine in RAM and then called that to do the erase /
program
> > stuff. Then I could "stand back" until the Flash was available
again
> > and return to the caller (write protected block in Flash).
> >
> > I suspect that is what Philips is doing, copying some Thumb code
into
> > those 32bytes to "stand back" until the current Flash operation
has
> > completed.
>
> They could have been even smarter. They could have pushed the 32
bytes code
> on the stack and executed them from there. The IAP code already
requires
> 128 bytes of stack space, and I guess that upping this to 160 bytes
and
> avoiding the top-of-RAM requirement would bite fewer people.
>
> In addition, an IAP entry for ARM mode would have been nice too.
If you
> have an ARM-only application, you now have to either:
>
> 1. Enable interworking, and its associated overhead, and do the
function
> pointer call as mentioned in the manual, or
>
> 2. Add something like this to an .s file (GNU gas):
>
> .global CallIAP
> .func CallIAP
> CallIAP:
> ldr r12, =0x7FFFFFF1
> bx r12
> .size CallIAP, . - CallIAP
> .endfunc
>
> and in a .c or .h file:
> void CallIAP (unsigned int *cmd, unsigned int *resp);
>
> With an ARM mode IAP entry in the boot block (which would consist
of the two
> instructions in method 2), you could use method 1 but without
having to
> enable interworking. This could also save some users' head
scratching.Show quoted textHide quoted text
>
> (Yes, these are suggestions for philips_apps, but I guess too late.)
>
> Karl Olsen
>