Lpc2000

Below is a draft of a possible sensible formal request we could make 
to Philips with regard to bootloader enhancement. It is simple and 
practical. 

If Philips agrees we can use interrupts by copying interrupt 
instructions and constant addresses to the start of RAM and setting 
MEMMAP to RAM mode. We can still use IAP features of the bootloader. 

There is no sense in replacing the bootloader if you accept it does 
its job as is: why chuck IAP when it works great and can be used to 
advantage in an enhancement, such as with USB enhanced bootloading?

John Heenan


Dear Philips

This is a formal request with regard to the bootloader of the LPC2xxx 
series of microcontrollers.

We are requesting a small enhancement to the bootloader whose end 
functionality is to 
- give us an option to bypass the pin 0.14 test by the bootloader 
when there has been an external reset
- perform our own bootload tasks taking advantage of IAP if we want to
- rejoin the bootloader informing the bootloader what we now want it 
to do or what we have done

For existing LPC2xxx parts with flash based bootloaders we are 
requesting you make an upgrade to the bootloader available to us.

For the bootloader to decide to bypass four items of information are 
necessary
1. Whether to bypass
2. Where to bypass to (in supervisor mode expecting ARM instructions)
3. Where we need to return to if we want to return ('BX LR' is a good 
option)
4. What should be specified in a register on return

On return perhaps R0 could have a value to indicate one of the above

- conduct a normal pin 0.14 test
- bypass pin 0.14 test as if test is true 
- bypass pin 0.14 test as if test was false
- we have used IAP functions to conduct our own bootloading: please 
restart the bootloader as if there was an external reset

Currently address 0x1FC is used to store the CRP value. If this value 
is 0x8765 4321 (or 0x4321 8765) then Code Read Protection (CRP )is 
enabled.

If CRP is not enabled then we request that if the CRP value is 0x4321-
--- or 0x----4321 where ---- represents four hexadecimal digits then 
these hexadecimal digits be used to decide a multiple of 4kB to jump 
to. For example if the CRP value is 0x4321 001E or 0x001E 4321 then 
this is interpreted to call address 0x1E (decimal 30) times 4kB = 
0x0007 B000. This is the start of sector 25 on the LPC2148 and is the 
start of the last 8kB of flash on the LPC2148.

Given that no flash sector can be less than 4kB for erase purposes 
(they are either 4kB or 32kB) then there is no advantage in 
specifying a finer resolution than 4kB as a multiple for call purposes

This request has the support of the following members of the LPC2000 
newsgroup on http://groups.yahoo.com/group/lpc2000/

John Heenan
Add your name if you support such a request!

John,

Interesting idea. Although simple in theory, I think you're actually 
asking quite a lot of Philips. Just think of all the documentation 
that would have to be updated to reflect the change. This all takes 
time, effort and cost that would have to be justified (ongoing costs 
as well in terms of updated training, support materials etc.)

Can you give some specific examples of what features and functions 
could be implemented if the loader were changed as you suggest? I 
think it would help both others and Philips to support such a move 
if there was more information on what could be achieved by such a 
change.

Brendan

--- In lpc2000@yahoogroups.com, "John Heenan" <l10@...> wrote:
>
> Below is a draft of a possible sensible formal request we could 
make 
> to Philips with regard to bootloader enhancement. It is simple and 
> practical. 
> 
> If Philips agrees we can use interrupts by copying interrupt 
> instructions and constant addresses to the start of RAM and 
setting 
> MEMMAP to RAM mode. We can still use IAP features of the 
bootloader. 
> 
> There is no sense in replacing the bootloader if you accept it 
does 
> its job as is: why chuck IAP when it works great and can be used 
to 
> advantage in an enhancement, such as with USB enhanced bootloading?
> 
> John Heenan
> 
> 
> Dear Philips
> 
> This is a formal request with regard to the bootloader of the 
LPC2xxx 
> series of microcontrollers.
> 
> We are requesting a small enhancement to the bootloader whose end 
> functionality is to 
> - give us an option to bypass the pin 0.14 test by the bootloader 
> when there has been an external reset
> - perform our own bootload tasks taking advantage of IAP if we 
want to
> - rejoin the bootloader informing the bootloader what we now want 
it 
> to do or what we have done
> 
> For existing LPC2xxx parts with flash based bootloaders we are 
> requesting you make an upgrade to the bootloader available to us.
> 
> For the bootloader to decide to bypass four items of information 
are 
> necessary
> 1. Whether to bypass
> 2. Where to bypass to (in supervisor mode expecting ARM 
instructions)
> 3. Where we need to return to if we want to return ('BX LR' is a 
good 
> option)
> 4. What should be specified in a register on return
> 
> On return perhaps R0 could have a value to indicate one of the 
above
> 
> - conduct a normal pin 0.14 test
> - bypass pin 0.14 test as if test is true 
> - bypass pin 0.14 test as if test was false
> - we have used IAP functions to conduct our own bootloading: 
please 
> restart the bootloader as if there was an external reset
> 
> Currently address 0x1FC is used to store the CRP value. If this 
value 
> is 0x8765 4321 (or 0x4321 8765) then Code Read Protection (CRP )is 
> enabled.
> 
> If CRP is not enabled then we request that if the CRP value is 
0x4321-
> --- or 0x----4321 where ---- represents four hexadecimal digits 
then 
> these hexadecimal digits be used to decide a multiple of 4kB to 
jump 
> to. For example if the CRP value is 0x4321 001E or 0x001E 4321 
then 
> this is interpreted to call address 0x1E (decimal 30) times 4kB = 
> 0x0007 B000. This is the start of sector 25 on the LPC2148 and is 
the 
> start of the last 8kB of flash on the LPC2148.
> 
> Given that no flash sector can be less than 4kB for erase purposes 
> (they are either 4kB or 32kB) then there is no advantage in 
> specifying a finer resolution than 4kB as a multiple for call 
purposes
> 
> This request has the support of the following members of the 
LPC2000 

> newsgroup on http://groups.yahoo.com/group/lpc2000/
> 
> John Heenan
> Add your name if you support such a request!
>

Brendan

Number of issues with scheme proposed so far.

1. For parts with an enhanced bootloader, if Philips declared CRP 
address 0x1FC to be a reserved address that may only contain 0x8765 
4321, 0x1234 8765 or default flash erase value of 0xFFFF FFFF and 
that anything else may lead to unpredictable results then Philips 
does not have to document anything further, no matter what bootloader 
enhancements are made. This would give time to iron out issues, 
prepare documentation and even withdraw the enhancement if so decided.

2. For a bootloader upgrade to existing LPC2xxx parts the same 
declaration would apply

3. Even if it was ensured the range of values in address 0x1FC all 
resolved to undefined ARM and Thumb instructions for the purpose of 
bootloader enhancement this is not good enough because it is 
legitimate to use address 0x1FC to contain any data value.

4. In a sense Philips has already sacrificed address 0x1FC. Given 
that there are two legitimate data values that cannot be placed at 
address 0x1FC if CRP is not to be enabled (0x8765 4321 and 0x4321 
8765).

4. The single biggest problem is the potential to lock an LPC2xxx 
part up permanently without an erase mechanism. However Philips would 
be covered by the simple statement 0x1FC is a reserved address that 
can only contain three values and that anything else may lead to 
unpredictable results including locking up the part.

5. The single biggest issue is the pin 0.14/DCD issue that currently 
requires a hardware solution. This can be solved in software by the 
proposal. The proposal also allow pin 0.14 functionality to be 
relocated.

6. With regard to other enhancements enabled by the proposal (such as 
independent bootloading using IAP and interrupts) none of them 
require the proposal. Bootloading through USB or any other data 
source can be done right now. The proposal simply makes programming 
and management slightly easier.

Basically it is just a proposal that would provide extra flexibility. 
I don't need it as I have no use for the DCD pin. I am not going to 
make it a cause and don't really want to spend time on making it a 
cause! There are marketing advantages. ATMEL gets a lot of mileage 
form its AVR bootload sectors with some extra hardware issues thrown 
in!

In summary 
- The proposed bootloader enhancements are easy to implement, add 
minor programming convenience and can relocate the bootload pin.
- Philips does not need to provide any further documentation with 
such an enhanced bootloader other than stating address 0x1FC is 
reserved and can only contain three values.
- Philips has already sacrificed address 0x1FC anyway from some 
legitimate data values.
- There are marketing advantages.

John Heenan


--- In lpc2000@yahoogroups.com, "brendanmurphy37" 
<brendanmurphy37@...> wrote:
>
> 
> John,
> 
> Interesting idea. Although simple in theory, I think you're 
actually 
> asking quite a lot of Philips. Just think of all the documentation 
> that would have to be updated to reflect the change. This all takes 
> time, effort and cost that would have to be justified (ongoing 
costs 
> as well in terms of updated training, support materials etc.)
> 
> Can you give some specific examples of what features and functions 
> could be implemented if the loader were changed as you suggest? I 
> think it would help both others and Philips to support such a move 
> if there was more information on what could be achieved by such a 
> change.
> 
> Brendan
> 
> --- In lpc2000@yahoogroups.com, "John Heenan" <l10@> wrote:
> >
> > Below is a draft of a possible sensible formal request we could 
> make 
> > to Philips with regard to bootloader enhancement. It is simple 
and 
> > practical. 
> > 
> > If Philips agrees we can use interrupts by copying interrupt 
> > instructions and constant addresses to the start of RAM and 
> setting 
> > MEMMAP to RAM mode. We can still use IAP features of the 
> bootloader. 
> > 
> > There is no sense in replacing the bootloader if you accept it 
> does 
> > its job as is: why chuck IAP when it works great and can be used 
> to 
> > advantage in an enhancement, such as with USB enhanced 
bootloading?
> > 
> > John Heenan
> > 
> > 
> > Dear Philips
> > 
> > This is a formal request with regard to the bootloader of the 
> LPC2xxx 
> > series of microcontrollers.
> > 
> > We are requesting a small enhancement to the bootloader whose end 
> > functionality is to 
> > - give us an option to bypass the pin 0.14 test by the bootloader 
> > when there has been an external reset
> > - perform our own bootload tasks taking advantage of IAP if we 
> want to
> > - rejoin the bootloader informing the bootloader what we now want 
> it 
> > to do or what we have done
> > 
> > For existing LPC2xxx parts with flash based bootloaders we are 
> > requesting you make an upgrade to the bootloader available to us.
> > 
> > For the bootloader to decide to bypass four items of information 
> are 
> > necessary
> > 1. Whether to bypass
> > 2. Where to bypass to (in supervisor mode expecting ARM 
> instructions)
> > 3. Where we need to return to if we want to return ('BX LR' is a 
> good 
> > option)
> > 4. What should be specified in a register on return
> > 
> > On return perhaps R0 could have a value to indicate one of the 
> above
> > 
> > - conduct a normal pin 0.14 test
> > - bypass pin 0.14 test as if test is true 
> > - bypass pin 0.14 test as if test was false
> > - we have used IAP functions to conduct our own bootloading: 
> please 
> > restart the bootloader as if there was an external reset
> > 
> > Currently address 0x1FC is used to store the CRP value. If this 
> value 
> > is 0x8765 4321 (or 0x4321 8765) then Code Read Protection (CRP )
is 
> > enabled.
> > 
> > If CRP is not enabled then we request that if the CRP value is 
> 0x4321-
> > --- or 0x----4321 where ---- represents four hexadecimal digits 
> then 
> > these hexadecimal digits be used to decide a multiple of 4kB to 
> jump 
> > to. For example if the CRP value is 0x4321 001E or 0x001E 4321 
> then 
> > this is interpreted to call address 0x1E (decimal 30) times 4kB = 
> > 0x0007 B000. This is the start of sector 25 on the LPC2148 and is 
> the 
> > start of the last 8kB of flash on the LPC2148.
> > 
> > Given that no flash sector can be less than 4kB for erase 
purposes 

> > (they are either 4kB or 32kB) then there is no advantage in 
> > specifying a finer resolution than 4kB as a multiple for call 
> purposes
> > 
> > This request has the support of the following members of the 
> LPC2000 
> > newsgroup on http://groups.yahoo.com/group/lpc2000/
> > 
> > John Heenan
> > Add your name if you support such a request!
> >
>

John,

I normally ask that one includes in the requirement only what one
wants, not how one wants it done.  If you do this, then you are not
likely to introduce undesirable side effects.

You want alternate boot loader intercepts like I said I wanted in the
free boot loader proposal.  I can see that the way you want it done
adds another method to how the LPC part can be locked out by software.

As it stands, the LPC can be locked out by software if the boot loader
is corrupted in way what it disables JTAG and then spin loops.

Consider your enhanced bootloader in which the the user enables CRP
*and* boot loader intercept, the intercept call does not return or
unconditionally returns "bypass as if P0.14 is false".

The part is now locked out by software and is as good as a OTP with
the application code as loaded and without boot loader functionality.

I would be surprised if Philips would implement your method and
introduce yet another software method by which users could lockout
their parts.

There are other issues but I have to explain these the context of what
the current boot loader on-chip does on startup, and why it is not a
good idea to branch to user code then back in the context of CRP.

Regards,

Jaya

--- In lpc2000@yahoogroups.com, "John Heenan" <l10@...> wrote:
>
> Below is a draft of a possible sensible formal request we could make 
> to Philips with regard to bootloader enhancement. It is simple and 
> practical. 
> 
> If Philips agrees we can use interrupts by copying interrupt 
> instructions and constant addresses to the start of RAM and setting 
> MEMMAP to RAM mode. We can still use IAP features of the bootloader. 
> 
> There is no sense in replacing the bootloader if you accept it does 
> its job as is: why chuck IAP when it works great and can be used to 
> advantage in an enhancement, such as with USB enhanced bootloading?
> 
> John Heenan
> 
> 
> Dear Philips
> 
> This is a formal request with regard to the bootloader of the LPC2xxx 
> series of microcontrollers.
> 
> We are requesting a small enhancement to the bootloader whose end 
> functionality is to 
> - give us an option to bypass the pin 0.14 test by the bootloader 
> when there has been an external reset
> - perform our own bootload tasks taking advantage of IAP if we want to
> - rejoin the bootloader informing the bootloader what we now want it 
> to do or what we have done
> 
> For existing LPC2xxx parts with flash based bootloaders we are 
> requesting you make an upgrade to the bootloader available to us.
> 
> For the bootloader to decide to bypass four items of information are 
> necessary
> 1. Whether to bypass
> 2. Where to bypass to (in supervisor mode expecting ARM instructions)
> 3. Where we need to return to if we want to return ('BX LR' is a good 
> option)
> 4. What should be specified in a register on return
> 
> On return perhaps R0 could have a value to indicate one of the above
> 
> - conduct a normal pin 0.14 test
> - bypass pin 0.14 test as if test is true 
> - bypass pin 0.14 test as if test was false
> - we have used IAP functions to conduct our own bootloading: please 
> restart the bootloader as if there was an external reset
> 
> Currently address 0x1FC is used to store the CRP value. If this value 
> is 0x8765 4321 (or 0x4321 8765) then Code Read Protection (CRP )is 
> enabled.
> 
> If CRP is not enabled then we request that if the CRP value is 0x4321-
> --- or 0x----4321 where ---- represents four hexadecimal digits then 
> these hexadecimal digits be used to decide a multiple of 4kB to jump 
> to. For example if the CRP value is 0x4321 001E or 0x001E 4321 then 
> this is interpreted to call address 0x1E (decimal 30) times 4kB = 
> 0x0007 B000. This is the start of sector 25 on the LPC2148 and is the 
> start of the last 8kB of flash on the LPC2148.
> 
> Given that no flash sector can be less than 4kB for erase purposes 
> (they are either 4kB or 32kB) then there is no advantage in 
> specifying a finer resolution than 4kB as a multiple for call purposes
> 
> This request has the support of the following members of the LPC2000 
> newsgroup on http://groups.yahoo.com/group/lpc2000/
> 
> John Heenan
> Add your name if you support such a request!

Count me out!

John,

just wanted to acknowledge we got the message and are looking into 
it. Will provide feedback once it is through internal evaluation.

Philips Apps


--- In lpc2000@yahoogroups.com, "John Heenan" <l10@...> wrote:
>
> Below is a draft of a possible sensible formal request we could 
make 
> to Philips with regard to bootloader enhancement. It is simple and 
> practical. 
> 
> If Philips agrees we can use interrupts by copying interrupt 
> instructions and constant addresses to the start of RAM and 
setting 
> MEMMAP to RAM mode. We can still use IAP features of the 
bootloader. 
> 
> There is no sense in replacing the bootloader if you accept it 
does 
> its job as is: why chuck IAP when it works great and can be used 
to 
> advantage in an enhancement, such as with USB enhanced bootloading?
> 
> John Heenan
> 
> 
> Dear Philips
> 
> This is a formal request with regard to the bootloader of the 
LPC2xxx 
> series of microcontrollers.
> 
> We are requesting a small enhancement to the bootloader whose end 
> functionality is to 
> - give us an option to bypass the pin 0.14 test by the bootloader 
> when there has been an external reset
> - perform our own bootload tasks taking advantage of IAP if we 
want to
> - rejoin the bootloader informing the bootloader what we now want 
it 
> to do or what we have done
> 
> For existing LPC2xxx parts with flash based bootloaders we are 
> requesting you make an upgrade to the bootloader available to us.
> 
> For the bootloader to decide to bypass four items of information 
are 
> necessary
> 1. Whether to bypass
> 2. Where to bypass to (in supervisor mode expecting ARM 
instructions)
> 3. Where we need to return to if we want to return ('BX LR' is a 
good 
> option)
> 4. What should be specified in a register on return
> 
> On return perhaps R0 could have a value to indicate one of the 
above
> 
> - conduct a normal pin 0.14 test
> - bypass pin 0.14 test as if test is true 
> - bypass pin 0.14 test as if test was false
> - we have used IAP functions to conduct our own bootloading: 
please 
> restart the bootloader as if there was an external reset
> 
> Currently address 0x1FC is used to store the CRP value. If this 
value 
> is 0x8765 4321 (or 0x4321 8765) then Code Read Protection (CRP )is 
> enabled.
> 
> If CRP is not enabled then we request that if the CRP value is 
0x4321-
> --- or 0x----4321 where ---- represents four hexadecimal digits 
then 
> these hexadecimal digits be used to decide a multiple of 4kB to 
jump 
> to. For example if the CRP value is 0x4321 001E or 0x001E 4321 
then 
> this is interpreted to call address 0x1E (decimal 30) times 4kB = 
> 0x0007 B000. This is the start of sector 25 on the LPC2148 and is 
the 
> start of the last 8kB of flash on the LPC2148.
> 
> Given that no flash sector can be less than 4kB for erase purposes 
> (they are either 4kB or 32kB) then there is no advantage in 
> specifying a finer resolution than 4kB as a multiple for call 
purposes
> 
> This request has the support of the following members of the 
LPC2000 

> newsgroup on http://groups.yahoo.com/group/lpc2000/
> 
> John Heenan
> Add your name if you support such a request!
>