Lpc2000

Hi,
Does anyone know if you can use the IAP routines
on an LPC2138 to write the flash while running
at crystal x6. I saw a note somewhere that said
you had to drop the clock multiplier to 1x to use
the IAP, but only prior to a certain version.

Has anyone tried this?

The Phillips boot loader gives evidence that you
must run at 1x because it can't go past 19200 baud
with 11.0592mhz. However the IAP routines may not
care what the multiplier is and it's just how the
bootloader sets up the PLL.

Landrum

Hello when you boot you can not run ISP from 60 MHz because the
autobauding would not work.  If you call IAP routines within you
program to change Flash contents, it is no problem to run as fast as
you want, but please use the frequency you are running at (e.g. 60
MHz) for the call. The actual f is needed to perform programming
correctly.  If you call IAP and tell the routine you are running at 10
MHz while in reality you are running at 60 MHz, it might program
sometimes but it is totally unreliable because it tries to program 6
times faster. 

hth, Bob

--- In lpc2000@yahoogroups.com, "lhaddix" <lhaddix@i...> wrote:

> Hi,
> Does anyone know if you can use the IAP routines
> on an LPC2138 to write the flash while running
> at crystal x6. I saw a note somewhere that said
> you had to drop the clock multiplier to 1x to use
> the IAP, but only prior to a certain version.
> 
> Has anyone tried this?
> 
> The Phillips boot loader gives evidence that you
> must run at 1x because it can't go past 19200 baud
> with 11.0592mhz. However the IAP routines may not
> care what the multiplier is and it's just how the
> bootloader sets up the PLL.
> 
> Landrum

Bob,
Thanks, that's the answer I was hoping for. I appreciate the
prompt and accurate assistance.

I need to run14.7456mhz * 4 with pclk 1:1 while updating
flash. I need to not miss chars in a serial stream during
flashing or lose cycles of a system tick so I have the interrupt
vector table and receive ISR in ram so I can continue running
while the IAP calls block in the foreground. I assume the IAP
can handle periodic interrupts while it is working as long as they
save context. Does this all sound reasonable?

Have you ever seen source for the IAP routines?

Have you ever seen source for the boot loader routines?

Have you seen a procedure for replacing the bootloader
with a custom version. If a .hex file places code in the bootloader
area (while it isn't  remapped) will the phillips flash utillity
correctly write it?

My project includes a requirement to replace the default boot loader
code with a version that boots from a different data format 
(a proprietary RS485 based protocol) so I need to make the 
'factory load' while the default ohillips loader is present  replace the
bootloader so subsequent re-flashings can be done over the 485 link.


Landrum Haddix
lhaddix@...
http://web.qx.net/lhaddix

Landrum,

what you describe sounds reasonable though not trivial. While
receiving characters, you need to have the int vectors remapped to the
SRAM and the ISR itself needs to be in SRAM too. 

There have been discussions about replacing the bootloader with
customized versions but as far as I remember the best argument from
Philips was that handling IAP can only be compatible across many
devices when one bootloader is always used. Modifying the bootloader
has significant risks for reliability of flash programming and I
understand that Philips does not want to risk any reliability and may
be liability issues.

Having the same calling convention even if the bootloader changes is
worth a lot for reusability of the code written for the LPC2000 devices.

Sometimes I wish the source would be published but I agree that the
potential chaos with modified bootloaders is not desirable. 

Bob

--- In lpc2000@yahoogroups.com, Landrum Haddix <lhaddix@i...> wrote:

> Bob,
> Thanks, that's the answer I was hoping for. I appreciate the
> prompt and accurate assistance.
> 
> I need to run14.7456mhz * 4 with pclk 1:1 while updating
> flash. I need to not miss chars in a serial stream during
> flashing or lose cycles of a system tick so I have the interrupt
> vector table and receive ISR in ram so I can continue running
> while the IAP calls block in the foreground. I assume the IAP
> can handle periodic interrupts while it is working as long as they
> save context. Does this all sound reasonable?
> 
> Have you ever seen source for the IAP routines?
> 
> Have you ever seen source for the boot loader routines?
> 
> Have you seen a procedure for replacing the bootloader
> with a custom version. If a .hex file places code in the bootloader
> area (while it isn't  remapped) will the phillips flash utillity
> correctly write it?
> 
> My project includes a requirement to replace the default boot loader
> code with a version that boots from a different data format 
> (a proprietary RS485 based protocol) so I need to make the 
> 'factory load' while the default ohillips loader is present  replace the
> bootloader so subsequent re-flashings can be done over the 485 link.
> 
> 
> Landrum Haddix
> lhaddix@i...
> http://web.qx.net/lhaddix

Bob,
> what you describe sounds reasonable though not trivial. While
> receiving characters, you need to have the int vectors remapped to the
> SRAM and the ISR itself needs to be in SRAM too. 

I've gotten this part implemented and tested. To get functions in ram
I created a new linker section with DATA for ram functions and modified
the startup.s to initialize them from the image in the TEXT section. I
use the GCC attribute function to place ram functions in that section.

To move the vector table I created a section at the start of DATA
where the ram vector table is located when not remapped then
made the vector table a 'naked' function (no entry/exit code)  containing
inline assembly for the table that gets relocated into that section.

It took some tinkering and staring at the .map and .lst files. I learned
more about .ld files than I wanted to know.

> There have been discussions about replacing the bootloader with
> customized versions but as far as I remember the best argument from
> Philips was that handling IAP can only be compatible across many
> devices when one bootloader is always used. Modifying the bootloader
> has significant risks for reliability of flash programming and I
> understand that Philips does not want to risk any reliability and may
> be liability issues.

I argued the case for keeping the default bootloader and was shot down
because it's a marketing requirement that this device flash update in
the same manner as our previous products to avoid confusing the 
installer.

I think what I will do is not modify the existing bootloader so that I
always have an assured simple way to update the flash and write
an additional  flash loader that executes in ram, understands the
proprietary 485 data and calls the IAP to update the flash.

This way the actual flash update would still use the Phillips supplied
IAP leaving the flash write details to Phillips.

If the flash loader resides in ram it can replace the entire flash
including it's own image in the TEXT segment.

Talk about spinning plates.<g>

Thank you, you have been extremely helpful. The LPC series is fantastic
but I've only been climbing the learning curve since March and there are
still plenty of mysteries

Landrum Haddix
lhaddix@...
http://web.qx.net/lhaddix