Lpc2000

Even without MEMMAP modifcation we could still use interrupt vectors!

You are right to clarify the MEMMAP point, although I had meant 
modifying whatever is behind MEMMAP at the register action level 
also. While memory remapping is implemented with pure hardware, the 
hardware required is minimal.

Without an additional MEMMAP option it is still possible to use 
interrupt vectors as long as no interrupt handlers within the 
bootloader are required after main application start. Bootloader 
interrupt instructions and their load addresses can be copied to RAM 
before the bootloader enables interrupts with MEMAP set for RAM 
interrupts. Of course these RAM locations would be overwritten after 
main program start. 

In fact even the above issues can be worked around by saving the 
start of RAM on the stack, as well as the contents of VIC registers, 
if a rentry into a bootloader function wanted to use interrupts.

The attraction of a bootloader code only modifcation approach is that 
we could upgrade our existing parts.

Think of it: USB bootloaders on our existing LPC214x parts that we 
write ourselves!  Bootloader pin on whatever port we want or none at 
all! Telling whiners to go away and produce something useful!

John Heenan


--- In lpc2000@yahoogroups.com, "Danish Ali" <danish@...> wrote:
>
> 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
> >
>