--- 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
Killing MCU by watching memory below 0x4000'0000 !?!
Started by ●June 26, 2006
Reply by ●June 26, 20062006-06-26
Reply by ●June 26, 20062006-06-26
--- In l..., "xray450" wrote:
> >
> > http://www.arm.com/iqonline/mem_currentissue/features/8217.html
> > this seems to be a password protected link...
Sorry I forgot to mention you have to be a member -- membership is
free and pretty immediate through here:
http://www.arm.com/iqonline/currentissue/members.html
Jaya
> >
> > http://www.arm.com/iqonline/mem_currentissue/features/8217.html
> > this seems to be a password protected link...
Sorry I forgot to mention you have to be a member -- membership is
free and pretty immediate through here:
http://www.arm.com/iqonline/currentissue/members.html
Jaya
Reply by ●June 26, 20062006-06-26
--- 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
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
Reply by ●June 26, 20062006-06-26
> 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
> 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
Reply by ●June 27, 20062006-06-27
--- 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
>
<- ...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
Reply by ●June 27, 20062006-06-27
--- 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
> 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
Reply by ●June 27, 20062006-06-27
> 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
> 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
Reply by ●June 27, 20062006-06-27
--- 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
> 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
Reply by ●June 27, 20062006-06-27
--- 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
> 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
Reply by ●June 27, 20062006-06-27
--- 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
>
> 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
