Hey all:
I would REALY rather not spend time writting these.
If someone has so much as "smell" as to where I can get my hands on
some already written assembly code to validate the CPU, instructions &
registers, would you please reply.
Thanks,
JP
ARM7 CPU Tests, Instruction Tests(ARM &/or THUMB) & Register Tests Wanted !!!
Started by ●October 22, 2007
Reply by ●October 22, 20072007-10-22
--- In l..., "jap136542" wrote:
>
> Hey all:
>
> I would REALY rather not spend time writting these.
>
> If someone has so much as "smell" as to where I can get my hands on
> some already written assembly code to validate the CPU, instructions &
> registers, would you please reply.
>
> Thanks,
>
> JP
>
There are 82000 hits on Google for 'arm cpu validation' including this
article by ARM: http://www.eetimes.com/isd/features/OEG20010228S0085
I would start with the nearest ARM office
http://www.arm.com/contact_us/offices.html
How do you know the assembler works?
Richard
>
> Hey all:
>
> I would REALY rather not spend time writting these.
>
> If someone has so much as "smell" as to where I can get my hands on
> some already written assembly code to validate the CPU, instructions &
> registers, would you please reply.
>
> Thanks,
>
> JP
>
There are 82000 hits on Google for 'arm cpu validation' including this
article by ARM: http://www.eetimes.com/isd/features/OEG20010228S0085
I would start with the nearest ARM office
http://www.arm.com/contact_us/offices.html
How do you know the assembler works?
Richard
Reply by ●October 23, 20072007-10-23
--- In l..., "rtstofer" wrote:
>
> --- In l..., "jap136542"
wrote:
> >
> > Hey all:
> >
> > I would REALY rather not spend time writting these.
> >
> > If someone has so much as "smell" as to where I can get my hands
on
> > some already written assembly code to validate the CPU,
instructions &
> > registers, would you please reply.
> >
> > Thanks,
> >
> > JP
> > There are 82000 hits on Google for 'arm cpu validation' including
this
> article by ARM: http://www.eetimes.com/isd/features/OEG20010228S0085
>
> I would start with the nearest ARM office
> http://www.arm.com/contact_us/offices.html
>
> How do you know the assembler works?
>
> Richard
>
Just out of curiosity, why does anyone think it necessary to do this
level of testing on parts such as the LPC2xxx? I'd thought that these
kinds of CPU verification were more for those integrating CPU cores
into FPGA/ASICs etc., rather than using an off-the-shelf ready-
integrated part such as the LPC2xxx.
Are the you looking for tests to verify the NXP design, or to detect
flaws in particular ICs?
Brendan
>
> --- In l..., "jap136542"
wrote:
> >
> > Hey all:
> >
> > I would REALY rather not spend time writting these.
> >
> > If someone has so much as "smell" as to where I can get my hands
on
> > some already written assembly code to validate the CPU,
instructions &
> > registers, would you please reply.
> >
> > Thanks,
> >
> > JP
> > There are 82000 hits on Google for 'arm cpu validation' including
this
> article by ARM: http://www.eetimes.com/isd/features/OEG20010228S0085
>
> I would start with the nearest ARM office
> http://www.arm.com/contact_us/offices.html
>
> How do you know the assembler works?
>
> Richard
>
Just out of curiosity, why does anyone think it necessary to do this
level of testing on parts such as the LPC2xxx? I'd thought that these
kinds of CPU verification were more for those integrating CPU cores
into FPGA/ASICs etc., rather than using an off-the-shelf ready-
integrated part such as the LPC2xxx.
Are the you looking for tests to verify the NXP design, or to detect
flaws in particular ICs?
Brendan
Reply by ●October 23, 20072007-10-23
Brendan
> Just out of curiosity, why does anyone think it necessary to do this
> level of testing on parts such as the LPC2xxx? I'd thought that these
> kinds of CPU verification were more for those integrating CPU cores
> into FPGA/ASICs etc., rather than using an off-the-shelf ready-
> integrated part such as the LPC2xxx.
>
> Are the you looking for tests to verify the NXP design, or to detect
> flaws in particular ICs?
I am not sure if the OP meant this kind of validation. For a IEC61508
certification we (the company I work for) must provide a runtime-cputest
to detect a faulty CPU. This cannot be a 100% test of course
(Mchhausen effect :-) )
--
42Bastian
> Just out of curiosity, why does anyone think it necessary to do this
> level of testing on parts such as the LPC2xxx? I'd thought that these
> kinds of CPU verification were more for those integrating CPU cores
> into FPGA/ASICs etc., rather than using an off-the-shelf ready-
> integrated part such as the LPC2xxx.
>
> Are the you looking for tests to verify the NXP design, or to detect
> flaws in particular ICs?
I am not sure if the OP meant this kind of validation. For a IEC61508
certification we (the company I work for) must provide a runtime-cputest
to detect a faulty CPU. This cannot be a 100% test of course
(Mchhausen effect :-) )
--
42Bastian
Reply by ●October 23, 20072007-10-23
why on earth do you expect to meet a non-functioning CPU... and do you
really trust a non-functioning CPU to work well enough to tell you it's
non-functioning?
I an just about see the point of a quick read-write check on a 256K
on-board cache... but beyond that, what's driving you to bother? Are you
building your own?
I once met an 8080 which couldn't increment register E ... but that was
30 years ago, and it was about number 77 off the production line.
David
> *Subject:* [lpc2000] ARM7 CPU Tests, Instruction Tests(ARM &/or
> THUMB) & Register Tests Wanted !!!
> *From:* "jap136542"
> *To:* l...
> *Date:* Mon, 22 Oct 2007 20:24:26 -0000
>
> Hey all:
>
> I would REALY rather not spend time writting these.
>
> If someone has so much as "smell" as to where I can get my hands on
> some already written assembly code to validate the CPU,
> instructions & registers, would you please reply.
>
> Thanks,
>
> JP
>
> --
> *Included Files:*
> am2file:001-HTML_Message.html
really trust a non-functioning CPU to work well enough to tell you it's
non-functioning?
I an just about see the point of a quick read-write check on a 256K
on-board cache... but beyond that, what's driving you to bother? Are you
building your own?
I once met an 8080 which couldn't increment register E ... but that was
30 years ago, and it was about number 77 off the production line.
David
> *Subject:* [lpc2000] ARM7 CPU Tests, Instruction Tests(ARM &/or
> THUMB) & Register Tests Wanted !!!
> *From:* "jap136542"
> *To:* l...
> *Date:* Mon, 22 Oct 2007 20:24:26 -0000
>
> Hey all:
>
> I would REALY rather not spend time writting these.
>
> If someone has so much as "smell" as to where I can get my hands on
> some already written assembly code to validate the CPU,
> instructions & registers, would you please reply.
>
> Thanks,
>
> JP
>
> --
> *Included Files:*
> am2file:001-HTML_Message.html
Reply by ●October 23, 20072007-10-23
David
> why on earth do you expect to meet a non-functioning CPU... and do you
> really trust a non-functioning CPU to work well enough to tell you it's
> non-functioning?
In safety critical system if humans may be hurt or even killed because
of a non- or malfunctioning control-unit you have to test all parts
within a certain time. This includes the CPU.
Think of a system that once switched on will run for years and may
be used in rather (chip)unfriendly environments like e.g. space.
> I once met an 8080 which couldn't increment register E ... but that was
> 30 years ago, and it was about number 77 off the production line.
Ask NXP if they give you a guarantee that a specific controller will
function 100% in a defined environment. I guess they won't give you
anything. Most manufactures exclude the use of their products in
medical equipement.
--
42Bastian
> why on earth do you expect to meet a non-functioning CPU... and do you
> really trust a non-functioning CPU to work well enough to tell you it's
> non-functioning?
In safety critical system if humans may be hurt or even killed because
of a non- or malfunctioning control-unit you have to test all parts
within a certain time. This includes the CPU.
Think of a system that once switched on will run for years and may
be used in rather (chip)unfriendly environments like e.g. space.
> I once met an 8080 which couldn't increment register E ... but that was
> 30 years ago, and it was about number 77 off the production line.
Ask NXP if they give you a guarantee that a specific controller will
function 100% in a defined environment. I guess they won't give you
anything. Most manufactures exclude the use of their products in
medical equipement.
--
42Bastian
Reply by ●October 23, 20072007-10-23
> > why on earth do you expect to meet a
non-functioning CPU... and
> > do you
> > really trust a non-functioning CPU to work well enough to tell
> > you it's
> > non-functioning?
>
> In safety critical system if humans may be hurt or even killed
> because
> of a non- or malfunctioning control-unit you have to test all parts
> within a certain time. This includes the CPU.
> Think of a system that once switched on will run for years and may
> be used in rather (chip)unfriendly environments like e.g. space.
Hald the problems with spacecraft seem to be caused by them failing
self-test then doing something which is menat to be helpful, but couldn't
be tested on the ground and actually makes them go out of control
totally.
I can see that shutting down a system if the CPU test fails would be
reasonable.
D.
> > do you
> > really trust a non-functioning CPU to work well enough to tell
> > you it's
> > non-functioning?
>
> In safety critical system if humans may be hurt or even killed
> because
> of a non- or malfunctioning control-unit you have to test all parts
> within a certain time. This includes the CPU.
> Think of a system that once switched on will run for years and may
> be used in rather (chip)unfriendly environments like e.g. space.
Hald the problems with spacecraft seem to be caused by them failing
self-test then doing something which is menat to be helpful, but couldn't
be tested on the ground and actually makes them go out of control
totally.
I can see that shutting down a system if the CPU test fails would be
reasonable.
D.
Reply by ●October 23, 20072007-10-23
Hi JP,
look at this article: "Deterministic Software-Based Self-Testing of
Embedded Processor Cores" (http://date.eda-
online.co.uk/proceedings/papers/2001/date01/pdffiles/02c_2.pdf).
Although it doesn't describe instruction tests, it covers testing of
ALU, MAC and shifter of the CPU. Included sample code
has been written for ARM9TDMI, but should be portable to ARM7 easily.
Rainer
--- In l..., "jap136542"
wrote:
>
> Hey all:
>
> I would REALY rather not spend time writting these.
>
> If someone has so much as "smell" as to where I can get my hands on
> some already written assembly code to validate the CPU,
instructions
&
> registers, would you please reply.
>
> Thanks,
>
> JP
>
look at this article: "Deterministic Software-Based Self-Testing of
Embedded Processor Cores" (http://date.eda-
online.co.uk/proceedings/papers/2001/date01/pdffiles/02c_2.pdf).
Although it doesn't describe instruction tests, it covers testing of
ALU, MAC and shifter of the CPU. Included sample code
has been written for ARM9TDMI, but should be portable to ARM7 easily.
Rainer
--- In l..., "jap136542"
wrote:
>
> Hey all:
>
> I would REALY rather not spend time writting these.
>
> If someone has so much as "smell" as to where I can get my hands on
> some already written assembly code to validate the CPU,
instructions
&
> registers, would you please reply.
>
> Thanks,
>
> JP
>
Reply by ●October 23, 20072007-10-23
Thanks Rainer ! That is just what I was looking for !
======================Set mode = ON_TOP_SOAP_BOX;
I've been involved with this lpc2000 group for several months now.
I get every posting e-mailed to me.
I'm thinking of making that stop, and to never again share what I've
learned, mostly because some people seem to treat this place more
like a chat room, than a meaningful exchange of information
pertaining to the LPX2xxx family of micros.
I ask you all, in the nicest possible way:
Please, please, please... keep the content focused on the family of
micros.
Thank-you & no replies this message are needed or wanted.
Set mode = OFF_OF_SOAP_BOX;
======================On the chance that a question asked earlier was sincere:
The reason that the CPU is tested, (also RAM, FLASH, and every other
reachable chunk of hardware) dynamically, is because hardware fails.
Simple as that. In MY world you ASSUME the harware is BAD until you
proove it good.
There exists organizations (UL, CSA, TUV, FM & others) that will
review both your hardware and firmware EXTENSIVLY, before they will
allow you to put their symbol on your product. These agencies employ
very sharp people, whom you will pay ridiculous sums of $$, to come
to you place of work and do everything humanly possible to make your
product fail in an "unsafe" way. They are allowed to insert two
hardware faults anywhere they want. Your product must either fail in
a "safe" way, or continue to operate normally. They will have you
set break points in you code, flip ram bits and do other things to
insert faults, and insure your code finds the fault. If you have a
weak spot in you firmware diagnostics, they WILL find it.
A "safe" failure is defined by the nature of the product. Most of
the time, in our business, it means DE-energizing a(some) relay(s)
within a prescribed amount of time (usually 1 second), signaling an
alarm condition, and preventing that relay from becoming energized
until there is some sort human intervention.
Without going into it too much, The Main micro is usually monitored
by a secondary micro (not of the same ilk) (or maybe a CPLD or
FPGA). One watches the other. Both are in the relay(s) control
loop.
JP
--- In l..., "xray450" wrote:
>
> Hi JP,
>
> look at this article: "Deterministic Software-Based Self-Testing of
> Embedded Processor Cores" (http://date.eda-
> online.co.uk/proceedings/papers/2001/date01/pdffiles/02c_2.pdf).
> Although it doesn't describe instruction tests, it covers testing
of
> ALU, MAC and shifter of the CPU. Included sample code
> has been written for ARM9TDMI, but should be portable to ARM7
easily.
>
> Rainer
>
> --- In l..., "jap136542"
> wrote:
> >
> > Hey all:
> >
> > I would REALY rather not spend time writting these.
> >
> > If someone has so much as "smell" as to where I can get my hands
on
> > some already written assembly code to validate the CPU,
> instructions
> &
> > registers, would you please reply.
> >
> > Thanks,
> >
> > JP
>
======================Set mode = ON_TOP_SOAP_BOX;
I've been involved with this lpc2000 group for several months now.
I get every posting e-mailed to me.
I'm thinking of making that stop, and to never again share what I've
learned, mostly because some people seem to treat this place more
like a chat room, than a meaningful exchange of information
pertaining to the LPX2xxx family of micros.
I ask you all, in the nicest possible way:
Please, please, please... keep the content focused on the family of
micros.
Thank-you & no replies this message are needed or wanted.
Set mode = OFF_OF_SOAP_BOX;
======================On the chance that a question asked earlier was sincere:
The reason that the CPU is tested, (also RAM, FLASH, and every other
reachable chunk of hardware) dynamically, is because hardware fails.
Simple as that. In MY world you ASSUME the harware is BAD until you
proove it good.
There exists organizations (UL, CSA, TUV, FM & others) that will
review both your hardware and firmware EXTENSIVLY, before they will
allow you to put their symbol on your product. These agencies employ
very sharp people, whom you will pay ridiculous sums of $$, to come
to you place of work and do everything humanly possible to make your
product fail in an "unsafe" way. They are allowed to insert two
hardware faults anywhere they want. Your product must either fail in
a "safe" way, or continue to operate normally. They will have you
set break points in you code, flip ram bits and do other things to
insert faults, and insure your code finds the fault. If you have a
weak spot in you firmware diagnostics, they WILL find it.
A "safe" failure is defined by the nature of the product. Most of
the time, in our business, it means DE-energizing a(some) relay(s)
within a prescribed amount of time (usually 1 second), signaling an
alarm condition, and preventing that relay from becoming energized
until there is some sort human intervention.
Without going into it too much, The Main micro is usually monitored
by a secondary micro (not of the same ilk) (or maybe a CPLD or
FPGA). One watches the other. Both are in the relay(s) control
loop.
JP
--- In l..., "xray450" wrote:
>
> Hi JP,
>
> look at this article: "Deterministic Software-Based Self-Testing of
> Embedded Processor Cores" (http://date.eda-
> online.co.uk/proceedings/papers/2001/date01/pdffiles/02c_2.pdf).
> Although it doesn't describe instruction tests, it covers testing
of
> ALU, MAC and shifter of the CPU. Included sample code
> has been written for ARM9TDMI, but should be portable to ARM7
easily.
>
> Rainer
>
> --- In l..., "jap136542"
> wrote:
> >
> > Hey all:
> >
> > I would REALY rather not spend time writting these.
> >
> > If someone has so much as "smell" as to where I can get my hands
on
> > some already written assembly code to validate the CPU,
> instructions
> &
> > registers, would you please reply.
> >
> > Thanks,
> >
> > JP
>
