Lpc2000

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.
> 
> (Yes, these are suggestions for philips_apps, but I guess too late.)
> 
> Karl Olsen
>