Lpc2000

Hi John,

I think you have a good point. If we can agree how the bootloader
should be improved, and it remains compatible with existing
hardware*, perhaps they will find the time to do it.

One point though: I think the MEMMAP is done in hardware,
location 0xE01FC040 on lpc2292. So I don't see how a
bootloader rewrite can add an extra option here.
(It makes no sense to tell the bootloader to select the
RAM vectors since RAM could contain rubbish).

*this constraint could be a serious limitation. But Philips will
not want to break products made to their existing data sheets.

Regards,
Danish
--- In lpc2000@yahoogroups.com, "John Heenan" <l10@...> wrote:
>
> I suggest a formal request be made to Philips with regard to their 
> bootloader for the following minor enhancements.
> 
> None of these suggestions are strictly necessasry. The suggestions 
> would simply make working with the LPC slightly easier. The 
> suggestions are to enable a programmable flash space and interrupt 
> remap location modelled on the ATMEL AVR system while retaining their 
> current bootloader (which I have never had a problem with) which 
> would of course carry out the required security processing before 
> handing over control. The current IAP features could still be called.
> 
> For example the CRP flash memory location could have bits read 
> similar to ATMEL fuse bits to decide 
> 1. size of a special 'boot sector' at top of flash (AVRs typically 
> allow four fixed sizes)
> 2. whether interrupt vectors and so startup remaps to the start of 
> the special boot sector.
> 
> It would also be healthy to allow MEMMAP have another value to 
> indcate another remapped location for interrupt vectors.
> 
> There is clearly a lot of motivation for independent bootloaders. It 
> would make my programming tasks slightly easier. It could also solve 
> another problem by allowing independent assignment of the 'boot load' 
> pin, instead of pin 0.14 (which interferes with DCD input is used and 
> can be solved currently with the use of a hardware single logic OR 
> gate).
> 
> John Heenan
>