Forums

Chip Versions and Workarounds

Started by Danish Ali June 30, 2006
This is a philosophical question, and although I am
encountering it in relation to the LPC microcontrollers,
I feel sure it applies elsewhere as well.

Systems are too complicated to be bug-free.
I will provide firmware upgrades.
Philips admit confirmed bugs and suggest workarounds.

Some time later, Philips might revise the chip design,
so that a particular workaround is no longer necessary.

In the prototyping department, I have access to the
latest errata document, and can see the revision letter
on my lpc2xxx chip, so I know which workarounds I must
apply.

Now think forwards to software upgrade of a production
item, probably being performed on-site by an end user.
There is no way the user can be expected to dismantle
the product to identify which chip revision is inside.
So how can we know which software to run?

I guess I have to write my code containing all the
workarounds for all versions of the chip that I shipped.
But sometimes those workarounds might lead to reduced
performance or increased power consumption
(example: wake-up from sleep not possible over CAN).
If I can get away with it, I would like to avoid
the workaround code - on a product-by-product basis
- to give the best possible performance for each user.

So I would like to be able to know which hardware
revision a given chip is without having to read the
writing on the package.

If Philips were feeling helpful, they might code the
revision level as (well as the part number) somewhere
inside the chip, in the same block as the bootloader.
If they do (and document it), then I have failed to
find such information. The errata sheets only mention
the printing on the chip.
Does anyone know if it is there?

Assuming a batch of chips are all the same revision
level, I could code the revision code in some
non-volatile storage on my board (either in a spare
Flash location or outside the lpc2xxx).
My pcb revision is already coded by tying spare
GPIO lines either up or down by placed or non-placed
resistors.

Might it be possible to test for the presence of
some bugs at run-time?

What do other people do? Comments are welcomed.

Regards,
Danish

An Engineer's Guide to the LPC2100 Series

I asked pretty much the same question a while back and got a not
particularly helpful email back from the Philips Apps guys.

An on-chip revision register seems like such an obvious idea (and one
that is widely provided in other silicon products) that I am really
surprised that the LPC parts don't have it.

I did wonder if they would change the device ISP id's as the revisions
changed, but I've not heard about anything of this nature.

If you are interested here is the previous thread.

Andy..

http://groups.yahoo.com/group/lpc2000/message/12996

--- In l..., "Danish Ali" wrote:
>
> This is a philosophical question, and although I am
> encountering it in relation to the LPC microcontrollers,
> I feel sure it applies elsewhere as well.
>
> Systems are too complicated to be bug-free.
> I will provide firmware upgrades.
> Philips admit confirmed bugs and suggest workarounds.
>
> Some time later, Philips might revise the chip design,
> so that a particular workaround is no longer necessary.
>
> In the prototyping department, I have access to the
> latest errata document, and can see the revision letter
> on my lpc2xxx chip, so I know which workarounds I must
> apply.
>
> Now think forwards to software upgrade of a production
> item, probably being performed on-site by an end user.
> There is no way the user can be expected to dismantle
> the product to identify which chip revision is inside.
> So how can we know which software to run?
>
> I guess I have to write my code containing all the
> workarounds for all versions of the chip that I shipped.
> But sometimes those workarounds might lead to reduced
> performance or increased power consumption
> (example: wake-up from sleep not possible over CAN).
> If I can get away with it, I would like to avoid
> the workaround code - on a product-by-product basis
> - to give the best possible performance for each user.
>
> So I would like to be able to know which hardware
> revision a given chip is without having to read the
> writing on the package.
>
> If Philips were feeling helpful, they might code the
> revision level as (well as the part number) somewhere
> inside the chip, in the same block as the bootloader.
> If they do (and document it), then I have failed to
> find such information. The errata sheets only mention
> the printing on the chip.
> Does anyone know if it is there?
>
> Assuming a batch of chips are all the same revision
> level, I could code the revision code in some
> non-volatile storage on my board (either in a spare
> Flash location or outside the lpc2xxx).
> My pcb revision is already coded by tying spare
> GPIO lines either up or down by placed or non-placed
> resistors.
>
> Might it be possible to test for the presence of
> some bugs at run-time?
>
> What do other people do? Comments are welcomed.
>
> Regards,
> Danish
>

At 03:42 PM 6/30/2006 +0000, grapevinetech wrote:
>An on-chip revision register seems like such an obvious idea (and one
>that is widely provided in other silicon products) that I am really
>surprised that the LPC parts don't have it.

Widely? That must depend on your experience, I think I've only used one
micro with that sort of facility.

Robert

" 'Freedom' has no meaning of itself. There are always restrictions, be
they legal, genetic, or physical. If you don't believe me, try to chew a
radio signal. " -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

Robert Adsett wrote:
> At 03:42 PM 6/30/2006 +0000, grapevinetech wrote:
>
>>An on-chip revision register seems like such an obvious idea (and one
>>that is widely provided in other silicon products) that I am really
>>surprised that the LPC parts don't have it.
> Widely? That must depend on your experience, I think I've only used one
> micro with that sort of facility.

I've seen it on processors (the processor version register),
eg. most PowerPC processors have them, and cat /proc/cpuinfo
under Linux displays it. Linux then uses that info to determine
features or bug fixes.

The x86 has it too. I was messing with some real-mode x86
code, and used the CPUID command to figure out how
Linux determined the processor features

http://www.ovro.caltech.edu/~dwh/pacific/

Earlier x86 processors didn't have the feature, so there is
an Intel app note telling you have you can search for
instructions or registers that are present in each
version. They 'evolved' to the CPUID instruction.

I think that some ARM chips have a co-processor that
provides the version on some of the cores ... perhaps
its only on the cores that call themselves 'processors'
versus the lighter-weight microcontrollers.

Dave
David Hawkins wrote:
> Robert Adsett wrote:
>
>>At 03:42 PM 6/30/2006 +0000, grapevinetech wrote:
>>>An on-chip revision register seems like such an obvious idea (and one
>>>that is widely provided in other silicon products) that I am really
>>>surprised that the LPC parts don't have it.
>>Widely? That must depend on your experience, I think I've only used one
>>micro with that sort of facility.

>
> I think that some ARM chips have a co-processor that
> provides the version on some of the cores ... perhaps
> its only on the cores that call themselves 'processors'
> versus the lighter-weight microcontrollers.

The ARM-ARM says co-processor 15 is for the version register.
Its contents are:

Implementor, Variant, Architecture, Primary Part Number, Revision

So I guess the LPCs don't implement this ... its not an ARM7
thing, since the ARM-ARM contains comments on pre-ARM7 and post
ARM7 variants.

Dave

>>I think that some ARM chips have a co-processor that
>>provides the version on some of the cores ... perhaps
>>its only on the cores that call themselves 'processors'
>>versus the lighter-weight microcontrollers.
>
> The ARM-ARM says co-processor 15 is for the version register.
> Its contents are:
>
> Implementor, Variant, Architecture, Primary Part Number, Revision
>

The ARM7TDMI-S Technical reference manual has this to say:

The ARM7TDMI-S processor contains two internal coprocessors:
CP14 is the communications channel coprocessor
CP15 is the system control coprocessor for cache and MMU functions.

So the version register might be in there.

Anyone tried writing some code to access co-processor registers
on the LPC series?

Dave

--- In l..., David Hawkins wrote:
> Anyone tried writing some code to access co-processor registers
> on the LPC series?
>
> Dave

I expect MRC would trigger undefined exception. It is easy enough to
try executing "mrc p15, 0, r0, c0, c0", making sure you intercept all
exceptions.

Jaya

--- In l..., David Hawkins wrote:
>
>
>
> >>I think that some ARM chips have a co-processor that
> >>provides the version on some of the cores ... perhaps
> >>its only on the cores that call themselves 'processors'
> >>versus the lighter-weight microcontrollers.
> >
> > The ARM-ARM says co-processor 15 is for the version register.
> > Its contents are:
> >
> > Implementor, Variant, Architecture, Primary Part Number, Revision
> >
>
> The ARM7TDMI-S Technical reference manual has this to say:
>
> The ARM7TDMI-S processor contains two internal coprocessors:
> CP14 is the communications channel coprocessor
> CP15 is the system control coprocessor for cache and MMU
functions.
>
> So the version register might be in there.
>
> Anyone tried writing some code to access co-processor registers
> on the LPC series?
>
> Dave
>

I don't believe CP15 is implemented on the LPC2000 series.

Accessing a coprocessor that is not implemented will (should!)
generate an undefined instruction trap.

As an input to the original question, regardless of not whether the
micro has a version number that can be read, in practice it's
probably best to have a hardware version for the entire product
coded somewhere on it (pin straps on unused GPIO, a few bytes of
EEPROM or Flash spare etc.). That way you (a) are not reliant on the
feature being available and (b) you can cover everything in the
version number, not just the micro. If you allow s/w upgrades to
your product, the s/w itself can figure out if it is suitable for
the part and/or use different code for it.

In other words, on-board version numbers are a nice to have feature
but not absolutely required in the embedded world. Contrast this
with something like general purpose applications running on generic
PCs, where it is very useful for applications to be able to
determine at run time the capabilities of the processor they're
running on. This explains their presence on parts such as PowerPCs,
x86 etc.

Just my two cents worth...

Brendan.





>Grapevinetech wrote
>An on-chip revision register seems like such an obvious idea (and one
>that is widely provided in other silicon products) that I am really
>surprised that the LPC parts don't have it.

A register with the processor revision would be very useful. I often use
a block of protected FLASH memory to describe the hardware. This small
chunk of memory is usually only programmable with the boot loader code
in a protected memory area by the production boot loader tool. I usually
call this the HCB, Hardware Control Block. The HCB contains the product
name, hardware version, serial number and special installed feature
flags. The HCB is programmed only during production.

With an HCB the software can determine the hardware details at start up.
It can also be used by a custom boot loader to identify the hardware and
serial number details.

David
-----
uC Hobby Microcontrollers for Hobbyist
www.uCHobby.com i...@uchobby.com
-----
--- In l..., "David Fowler" wrote:
>
> >Grapevinetech wrote
> >An on-chip revision register seems like such an obvious idea (and one
> >that is widely provided in other silicon products) that I am really
> >surprised that the LPC parts don't have it.
>
> A register with the processor revision would be very useful. I often use
> a block of protected FLASH memory to describe the hardware. This small
> chunk of memory is usually only programmable with the boot loader code
> in a protected memory area by the production boot loader tool. I usually
> call this the HCB, Hardware Control Block. The HCB contains the product
> name, hardware version, serial number and special installed feature
> flags. The HCB is programmed only during production.

Those who feel obliged to use the LPC only in the way Philips tells
you to, please ignore the rest of this message.

All my boot loaders do this not only for functions you mentioned but
also to automatically generate (at factory load time) crypto-safe
serial numbers or keys.

Clients find the key approach particularly useful to target binaries
to specific customers through open channels.

I have boot loader deployed in LPCs with client's own crypto modules
for some time now ... but you would only do this if you are prepared
to replace the supplied boot loader.

> David
> -----
> uC Hobby Microcontrollers for Hobbyist
> www.uCHobby.com info@...
> -----

Jaya