--- In l..., "jayasooriah"
wrote:
> My understanding is that the LPC is the product of an initiative to
> redesign everything ground up (RAM, FLASH, CACHE UART, TIMERS,
etc) so
> as to produce a design that is cost effective.
>
> Each component had to be made simpler and the designers did this by
> cutting down transistors.

Do you have any information to back this assertion, or is it pure
speculation? It does not match my understanding of the origin of the
design.

> > > If they released this information anyone could "upgrade" their
part to
> > > the full silicon capabilities without limits imposed by
Philips "boot
> > > loader".

Do you have any information to back the assertion that such
an "upgrade" is possible, or is it pure speculation? It does not
match my understanding what is possible. As others have pointed out,
even if it were possible, it would be a very bad idea to use such an
undocumented "feature".

Brendan.

An Engineer's Guide to the LPC2100 Series

--- In l..., "derbaier" wrote:
>
> --- In l..., "jayasooriah" wrote:
> >
> > A feature of LPC's innovative design is the use of one a register to
> > limit amount RAM and ROM enabled. This is done in the supplied boot
> > loader and this is the real reason for keeping boot loader internals
> > secret.
> > That is an interesting allegation to make without any proof. The
> reasons stated by Phillips make more sense.

To my knowledge Philips has never made any statement about this.

All Philips has to do is to document bits of the special register at
0x3fff8000. Philips has not and the most compelling reason for this
is as I explained.

You are probably referring to speculation on the part of some forum
readers who appear not conversant with the exact what mechanism used
in the LPC to limit FLASH and RAM sizes.

Anyone can establish the truth (or otherwise) of the "allegation" by a
simple experiment. I have had independent confirmation of my findings
from those who bothered to do the experiment.

> There is no "innovative
> design" involved in mapping out defective RAM and FLASH since it has
> to be done by some method or other in all silicon designs that
> incorporate RAM and FLASH. Silicon defects are fairly randomly
> distributed, but since memory occupies such a larg die area memory is
> more freqeuntly hit by defects. It makes more economic sense to simply
> map out the defects rather than discarding the whole die. Otherwise we
> would all be paying higher prices for parts that were simply good/bad
> binned.

The "innovation" I was referring to relates to the LPC project itself.

My understanding is that the LPC is the product of an initiative to
redesign everything ground up (RAM, FLASH, CACHE UART, TIMERS, etc) so
as to produce a design that is cost effective.

Each component had to be made simpler and the designers did this by
cutting down transistors. The result is what we see -- rather unusual
bugs. Those of us in systems design classify bugs as "design" or
"implementation" and in the case of LPC, a large portion appear to be
in the "design" basket.

I am quite sure the recent discovery by another poster that SRAM on
LPC is really pseudo static dynamic RAM is not the last we will hear
of what is in the LPC family of processors.

If you worked out the bits in the register I referred to above that
controlled FLASH and RAM size, you cannot but conclude that it has not
to do with mapping out defective RAM or ROM cells.

> > If they released this information anyone could "upgrade" their part to
> > the full silicon capabilities without limits imposed by Philips "boot
> > loader".
>
> That is your allegation.

Philips can prove this "allegation" false. It has not.

> For a hobbiest, it might even be worth
> getting the capabilities that were not paid for. However, it is very
> likely that the mapped out memory has failed some corner cases during
> pre or post packaging testing, so it would make very little sense for
> a commercial project to "upgrade" parts by such methods.

This makes sense if register at 0x3fff8000 does what you think it
does. A simple experiment will demonstrate this is not the case.

>
> --Dave
>

Jaya

--- In l..., "jayasooriah" wrote:
>
> A feature of LPC's innovative design is the use of one a register to
> limit amount RAM and ROM enabled. This is done in the supplied boot
> loader and this is the real reason for keeping boot loader internals
> secret.
>

That is an interesting allegation to make without any proof. The
reasons stated by Phillips make more sense. There is no "innovative
design" involved in mapping out defective RAM and FLASH since it has
to be done by some method or other in all silicon designs that
incorporate RAM and FLASH. Silicon defects are fairly randomly
distributed, but since memory occupies such a larg die area memory is
more freqeuntly hit by defects. It makes more economic sense to simply
map out the defects rather than discarding the whole die. Otherwise we
would all be paying higher prices for parts that were simply good/bad
binned.

> If they released this information anyone could "upgrade" their part to
> the full silicon capabilities without limits imposed by Philips "boot
> loader".
>

That is your allegation. For a hobbiest, it might even be worth
getting the capabilities that were not paid for. However, it is very
likely that the mapped out memory has failed some corner cases during
pre or post packaging testing, so it would make very little sense for
a commercial project to "upgrade" parts by such methods.

--Dave

--- In l..., "unity0724" wrote:
> Hi,
> Had been using LPC21xx for >2 years, so far the chips' bootloader
> are robust and do not get corrupted easily.
>
> Only time I got the bootloader corrupted was trying to fix some
> chip ISP programming problems, about 2 years ago:
> - I change VCore from 1.8V to 2.1V-2.5V, in fixing some chip unable
> to be programmed by ISP. Bootloader could be corrupted when
> VCore is about 2.5V. "Symptom" is similar to yours.
> - That problem was fixed later by Philips acknowledged very old
> bootloader unable to burn/flash some chips properly, and new
> bootloader released.
>
> May be it helps with checking all your hardware circuit are correct
> first, then come back to fix your software.
> Regards

Thanks unity. I already checked the hardware but there is no error
as far as I can say. All voltages are stable and in range. I also
sacrificed a Keil eval board which is unlikely to have a hardware
bug. Bootloader versions were all 1.63 or 1.64 (even newer than in
the latest 'update' package).

Rainer

--- In l..., "rtstofer" wrote:

> Perhaps the regs are undocumented because Philips doesn't want them
> used. This could be because they don't want to commit forever and
> always to use a particular configuration.
>
> In this business there are tons of things that are either
undocumented or their use is documented but undefined.
>
> If it isn't documented, it probably shouldn't be used and is almost
> bound to change over time. And then you'll hear the whining...
>
> Richard
>

I never planned to make use of those register, although it would be
interesting what Philips' hiding there. But I simply feel kidded when
such essential system registers are concealed. And even worse:
information in the user manual is simply wrong:

"The LPC2119/2129/2194/2292/2294 generates the appropriate bus cycle
abort exception if an access is attempted for an address that is in a
reserved or unassigned address region. The regions are:
Areas of the memory map that are not implemented for a specific ARM
derivative. For the LPC2119/2129/2194/2292/2294, this is:
- Address space between On-Chip Non-Volatile Memory and On-Chip SRAM
(...) for 256 kB Flash device this range is from 0x0004 0000 to 0x3FFF
FFFF."

Rainer

> I already figured out, that access on the area between 0x3FFF'8000
> to 0x3FFF'FFFF is not raising a data abort. My problem definitely
> has nothing to do with an erroneous exception handler.
> All exception handlers are set up correctly (they end in a simple
> while(1) loop doing nothing currently).
> I also tried to read some addresses as you did. This did not lead
> to
> a damaged MCU.
> I don't know what side effects watching this area in the debugger
> via JTAG has to the microcontroller. In fact NO write access has
> been made by me. Also the death did not appear instantly after
> watching this mem area in the debugger. It needed some flash
> upload
> attempts (approx. 2 or 3) until the last updload failed with an
> timeout. But I don't believe it's accidentally to kill 4 MCUs in
> succession by simply load a 'hello world' program while having a
> read-only watch window open in the debugger (I tried even two
> different debuggers)!
>
> Rainer
>

Hi,
Had been using LPC21xx for >2 years, so far the chips' bootloader
are robust and do not get corrupted easily.

Only time I got the bootloader corrupted was trying to fix some
chip ISP programming problems, about 2 years ago:
- I change VCore from 1.8V to 2.1V-2.5V, in fixing some chip unable
to be programmed by ISP. Bootloader could be corrupted when
VCore is about 2.5V. "Symptom" is similar to yours.
- That problem was fixed later by Philips acknowledged very old
bootloader unable to burn/flash some chips properly, and new
bootloader released.

May be it helps with checking all your hardware circuit are correct
first, then come back to fix your software.
Regards

--- In l..., "rtstofer" wrote:
> Perhaps the regs are undocumented because Philips doesn't want them
> used. This could be because they don't want to commit forever and
> always to use a particular configuration.

A feature of LPC's innovative design is the use of one a register to
limit amount RAM and ROM enabled. This is done in the supplied boot
loader and this is the real reason for keeping boot loader internals
secret.

If they released this information anyone could "upgrade" their part to
the full silicon capabilities without limits imposed by Philips "boot
loader".

> In this business there are tons of things that are either undocumented
> or their use is documented but undefined.

People who need security (even if it is just for purposes of
protecting the design) tend to stay clear of such devices.

> If it isn't documented, it probably shouldn't be used and is almost
> bound to change over time. And then you'll hear the whining...

This is the biggest drawback of deferred designs when the initial
design is not extensible as good designs should be.

> Richard
>

Jaya

--- In l..., "xray450" wrote:
>
<- ...cut out... ->
> Peter,
>
> I already figured out, that access on the area between 0x3FFF'8000
> to 0x3FFF'FFFF is not raising a data abort. My problem definitely
> has nothing to do with an erroneous exception handler.
> All exception handlers are set up correctly (they end in a simple
> while(1) loop doing nothing currently).
> I also tried to read some addresses as you did. This did not lead to
> a damaged MCU.
> I don't know what side effects watching this area in the debugger
> via JTAG has to the microcontroller. In fact NO write access has
> been made by me. Also the death did not appear instantly after
> watching this mem area in the debugger. It needed some flash upload
> attempts (approx. 2 or 3) until the last updload failed with an
> timeout. But I don't believe it's accidentally to kill 4 MCUs in
> succession by simply load a 'hello world' program while having a
> read-only watch window open in the debugger (I tried even two
> different debuggers)!
>
> Rainer
>

It appears by what you said, that reading a register (by the jtag)
at a critical time either set/clears a status bit that was unexpected
by the API's program flow, or interrupts the flash programming
operation because of the read, (remembering how the watchdog access
MUST be in exact order) and leads the API towards the meltdown you
describe.

Just so we are all on the same page.

- Gary

> I agree that using undocumented regs to implement some kind
> of 'security' features is very poor. If this is for the copy
> protection reason (is it??), why didn't Philips use ordinary fuse
> bits like any other micro? OK for this silicon step it's too late.
> But the next revision is to be due anyway (see errata).
>

Perhaps the regs are undocumented because Philips doesn't want them
used. This could be because they don't want to commit forever and
always to use a particular configuration.

In this business there are tons of things that are either undocumented
or their use is documented but undefined.

If it isn't documented, it probably shouldn't be used and is almost
bound to change over time. And then you'll hear the whining...

Richard

--- In l..., "jayasooriah"
wrote:
>
> --- In l..., Dominic Rath wrote:
> > That might be what the user manual says, but of course the user
> manual only
> > describes the view Philips wants you to have - this isn't
ncessarily
> a bad
> > thing, and using a non-documented way of flash writing for
example
> might be
> > even worse, but in this case it doesn't make Philips look too
good.
>
> Apologies for going off-topic a bit ...
>
> It is worth noting that I would not have gone into the boot loader
or
> into the undocumented registers if not for the fact that I had
parts
> destroyed by software much like in the case of Reiner.
>
> However, having gone down this path, it is worth nothing that had
> Philips documented these registers, we would all be able to:
>
> 1) erase non-contagious sectors as a single erase operation;
>
> 2) terminate pending erase/write if we wished, for example, to
take an
> interrupt using ISR running from on-chip flash without being locked
> out for 400 ms; and
>
> 3) (may be) keep the voltage multiplier running (possibly consuming
> more power) and erase flash sectors in 4ms instead of 400ms.
>
> That above cannot be done because of limitations in the supplied
boot
> loader software (and not the LPC hardware) works against Philips.
>
> Jaya
>

I agree that using undocumented regs to implement some kind
of 'security' features is very poor. If this is for the copy
protection reason (is it??), why didn't Philips use ordinary fuse
bits like any other micro? OK for this silicon step it's too late.
But the next revision is to be due anyway (see errata).

In my opinion registers either have to be documented or they
have to be invisible for the user application, so they
can't lead to damage or unexpected behavior. My company develops
safety relevant products, for example. What if I had rely on the
statement in the user manual, that every access on reserved or
unassigned regions leads to an exception? Instead a simple stack
overflow may lead to unpredictable behavior or damage of the MCU!
Sorry for beeing upset. I've to resolder four MCUs now. At least
they are no BGAs...

I would prefer having a completely documented MCU and renounce
having a weak copy protection which is cracked sooner or later.
Philips couldn't have been such silly to think, this would be
undiscovered? At least they could have used some other addresses in
the 4GB memory space, which would have been not so easy to guess...

Rainer