Lpc2000

---- Original Message ----
From: "Tom Walsh" <tom@...>
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