Searching \ for '[PIC]: What's "instruction set test"?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'What's "instruction set test"?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: What's "instruction set test"?'
2002\08\20@102724 by Tony Pan

picon face
Hi,

Can someone tell me what's instruction set test?

It is supposed to be the execution of a set of instructions to verify if the
result of the instructions match a known value. If it doesn't, it indicates
the program has corrupted.

This is all I know; but I need more details. Can someone kindly fill in more
details?

Thanks in advance,
Tony

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@105148 by Alan B. Pearce

face picon face
>Can someone tell me what's instruction set test?

>It is supposed to be the execution of a set of instructions to verify if
the
>result of the instructions match a known value. If it doesn't, it indicates
>the program has corrupted.

I have seen it done on a Z80, I doubt a PIC has enough memory to do it, and
contain more than a tiny application, unless someone can figure how to do it
in the 12 instructions :)

The example I saw would go through the instruction set, testing the
functionality of each instruction, verifying flags were set correctly, and
registers correctly addressed, and containing correct contents, before
starting on the application code. IIRC on a Z80 this took somewhere around
0.5 to 1k of code space, and used a byte or two of ram to verify writing
capability.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@111132 by Scott Dattalo

face
flavicon
face
On Tue, 20 Aug 2002, Alan B. Pearce wrote:

> >Can someone tell me what's instruction set test?
>
> >It is supposed to be the execution of a set of instructions to verify if
> the
> >result of the instructions match a known value. If it doesn't, it indicates
> >the program has corrupted.
>
> I have seen it done on a Z80, I doubt a PIC has enough memory to do it, and
> contain more than a tiny application, unless someone can figure how to do it
> in the 12 instructions :)
>
> The example I saw would go through the instruction set, testing the
> functionality of each instruction, verifying flags were set correctly, and
> registers correctly addressed, and containing correct contents, before
> starting on the application code. IIRC on a Z80 this took somewhere around
> 0.5 to 1k of code space, and used a byte or two of ram to verify writing
> capability.

I agree that this is not practical on a PIC. But you can get an idea of a
very simple tester here:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gpsim/examples/14bit/it.asm

This is a program that tests how well gpsim (gnupic simulator) can
simulate a PIC. The program is not useful for anything but testing gpsim.

It might be practical to test some of the basic/common things. For
example, you could exercise all of the bits in the status register, test
indirect addressing, verify TMR0 works, etc.

Scott

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@111138 by Olin Lathrop

face picon face
>Can someone tell me what's instruction set test?
>
>It is supposed to be the execution of a set of instructions to verify if
the
>result of the instructions match a known value. If it doesn't, it indicates
>the program has corrupted.

Why do you want to do this?  Performing an instruction test on a single chip
micro seems rather pointless to me.  Instruction tests used to be popular
back when a computer was on a bunch of boards and there could be failurs
inside the CPU.  The likelyhood of blowing an individual transistor inside
the CPU of a single chip micro is vanishingly small.  When chips go bad, it
is usually the I/O drivers, power related, or in the case of some PICs the
flash could wear out.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@112213 by Alan B. Pearce

face picon face
>>Can someone tell me what's instruction set test?

>Why do you want to do this?  Performing an instruction test on a single
chip

It sounds like a requirement of safety testing labs, as has been discussed
here before in regard to queries about ROM checksums. It seems the funny
sort of test they might require.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@112622 by Tony Pan

picon face
>> Why do you want to do this?

To comply with the UL1998 requirement, I need to test the integrity of the
ROM. The chip that I am using is not capable of accessing program memory.
Therefore the UL engineer told me that I can perform instruction set test
instead. But he didn't tell me how to do it.

Do I have to test ALL instructions? Or just the ones that I use in my
program?

Thanks,
Tony


{Original Message removed}

2002\08\20@112835 by Tony Pan

picon face
Exactly. For UL1998.

The UL engineer said he cannot tell me how to do it due to conflict of
interests. That leaves me in the dark.

Has anybody gone though this before?

Tony

{Original Message removed}

2002\08\20@120220 by Olin Lathrop

face picon face
> >> Why do you want to do this?
>
> To comply with the UL1998 requirement, I need to test the integrity of the
> ROM. The chip that I am using is not capable of accessing program memory.
> Therefore the UL engineer told me that I can perform instruction set test
> instead. But he didn't tell me how to do it.

An instruction set test won't test the whole ROM, only the locations that
hold the instruction you end up testing.  In other words, you will only be
verifying the ROM data paths.  The individul ROM locations you will verify
will be exactly those that DON'T matter in normal operation.  The normal
procedure for testing ROM is to perform a checksum.  If the machine can't
read its own ROM, then you probably can't comply with that requirement using
that machine.

A last desparate method would be to use the ROM programming feature to read
it out and perform the checksum, but that would require external hardware.
A different PIC that can read its own program memory would be cheaper.  Of
course how do you know then that the ROM holding the checksum algorithm
didn't flake out and cause the routine to report everything is OK?


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@122104 by Spehro Pefhany

picon face
At 11:11 AM 8/20/02 -0400, you wrote:

>Why do you want to do this?  Performing an instruction test on a single chip
>micro seems rather pointless to me.  Instruction tests used to be popular
>back when a computer was on a bunch of boards and there could be failurs
>inside the CPU.  The likelyhood of blowing an individual transistor inside
>the CPU of a single chip micro is vanishingly small.  When chips go bad, it
>is usually the I/O drivers, power related, or in the case of some PICs the
>flash could wear out.

It's a specific requirement of the standard- IOW, it's too late to argue
about the relative merits of it.

Considering the number of bad dies per wafer is significant, there is a
100% chance that some marginal ones will slip through and fail
later if your sample is large enough. For non-MIL spec chips, I don't think
they even visually look at the chip to see if anything is horribly wrong.

Since this standard is specifically for *safety critical* applications,
consumer (high) volume products could result in an unacceptable level of
personal injury or property damage. While I do agree with Olin that some of
the testing is on the diminishing returns end, the overhead required is minimal
and there will be some improvement in reliability (it's not like the complexity
introduces significant failure modes itself). The ROM check just
happens to be a problem with PICs, and few other architectures. Who knows,
maybe a Motorola or Intel employee on the committee pushed it forward. It's
hard to argue against something that takes minimal resources and can only help
reduce the number of deaths etc.

If the micro can't do anything that could cause a safety hazard, no matter
how nuts or paralyzed it goes, you *don't* need to meet this particular
standard.

Best regards.

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
spam_OUTspeffTakeThisOuTspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
9/11 United we Stand

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@134223 by llile

flavicon
face
Tony,

There are two ways to go regarding UL1998.  First, you are required to
comply with UL1998 if the failure of your microcontroller control could
result in "unsafe"  operation of your product (defined in narrow terms by
UL).  Now, if this is the case, UL will consider the control "Unreliable",
and require you to test the product with the controls shorted out in
various ways, effectively "failed".

If you are designing a medical device, you probably are in UL1998
territory.  If you are designing a consumer product, a clock,  or an audio
product for instance, you should specifically ask that yopur product be
tested as if the control is "unreliable".  That triggers a whole different
set of concerns.

IMHO, the PIC Flash parts that are able to read their own program memory
could possibly comply with UL1998 by simply doing a checksum on their own
memory.  If your processor is incapable of this, you are probalby screwed
unless you upgrade the processor.

If your control is deemed "unreliable", you will have to show that the
product does not overheat, connect the case to the mains, melt or catch on
fire if the control is shorted and the product is left on and  shoved up
against a piece of plywood (a UL Alcove).   Often people add thermal
cutout fuses and other failsafe devices to pass this test.   If it is a
medical device, you have to show it won't zap anybody if the control is
shorted out.


Can you tell us in general terms what kind of product you have?  Medical,
consumer product, heating device, motorized product, timing device, audio
device, industrial control?


-- Lawrence Lile
Senior Project Engineer
Toastmaster, Inc.
Division of Salton, Inc.
573-446-5661 voice
573-446-5676 fax




Tony Pan <.....weidong.panKILLspamspam@spam@VERIZON.NET>
Sent by: pic microcontroller discussion list <PICLISTspamKILLspamMITVMA.MIT.EDU>
08/20/02 10:28 AM
Please respond to pic microcontroller discussion list


       To:     .....PICLISTKILLspamspam.....MITVMA.MIT.EDU
       cc:
       Subject:        Re: [PIC]: What's "instruction set test"?


Exactly. For UL1998.

The UL engineer said he cannot tell me how to do it due to conflict of
interests. That leaves me in the dark.

Has anybody gone though this before?

Tony

{Original Message removed}

2002\08\20@135400 by Barry Gershenfeld

face picon face
>Of course how do you know then that the ROM holding the checksum algorithm
>didn't flake out and cause the routine to report everything is OK?

Wow, I practically got to the end of this thread before anyone
asked some obvious questions.

And what if BTFSS malfunctioned?  How would you "test" for that?

Yet, even the IBM PC BIOS had (has?) instruction set tests.

Am I insane?  *I* don't think so!   :)

Barry


{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@135422 by Tony Pan

picon face
Hi Lawrence,

We are writing an oil burner, a heating device. We have gone through the UL software audit and are found that we need to implement ROM and RAM test. Others requirements have been taken care of. I finished RAM test. Now for ROM test, an instruction set test is what we need to do. Do I need to test just a few instructions? Or all instructions that I use in the code?

Thanks,
Tony


 {Original Message removed}

2002\08\20@143905 by Wouter van Ooijen

face picon face
> And what if BTFSS malfunctioned?  How would you "test" for that?

Make sure that the normal code is reached only when one BTFSS fails (in
the sense that it does not skip) and a second one does skip.

> Am I insane?  *I* don't think so!   :)

Did you test that, and did you checksum your firmware?

Wouter

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@144330 by Spehro Pefhany

picon face
At 10:40 AM 8/20/02 -0700, you wrote:
> >Of course how do you know then that the ROM holding the checksum algorithm
> >didn't flake out and cause the routine to report everything is OK?

An 8-bit checksum has a 1 in 256 chance of giving a false "okay" anyhow.
But that is 256 times better than not checking at all.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
EraseMEspeffspam_OUTspamTakeThisOuTinterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
9/11 United we Stand

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\21@043211 by Carlos Ojea

flavicon
face
>
>To comply with the UL1998 requirement, I need to test the integrity of the
>ROM. The chip that I am using is not capable of accessing program memory.
>Therefore the UL engineer told me that I can perform instruction set test
>instead. But he didn't tell me how to do it.
>
>Do I have to test ALL instructions? Or just the ones that I use in my
>program?
>



Which UL standard is more suitable to pic applications?

Carlos

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\08\21@161940 by Peter L. Peres

picon face
On Tue, 20 Aug 2002, Spehro Pefhany wrote:

>At 10:40 AM 8/20/02 -0700, you wrote:
>> >Of course how do you know then that the ROM holding the checksum algorithm
>> >didn't flake out and cause the routine to report everything is OK?
>
>An 8-bit checksum has a 1 in 256 chance of giving a false "okay" anyhow.
>But that is 256 times better than not checking at all.

And more exactly, there is NO way to have a 1 in infinity chances of being
wrong. So what does UL1998 (?) specify ? > 1:2^N where N is the number of
rom bits you have ? ;-) Solving things by (incompetent) commitee has got
enough history by now that people would notice these things, no ? Are they
saying that 'just testing it' is enough or is there a target number ?

Peter

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\08\21@171950 by Tony Pan

picon face
>> So what does UL1998 (?) specify ? > 1:2^N where N is the number of rom
bits you have ? ;-)
>> Are they saying that 'just testing it' is enough or is there a target
number ?

Depend on the type of your application, the UL1998 requires you to do either
16-bit or 32-bit CRC.

If you don't do CRC, you can choose to do other tests on their list. You can
even come up with your own test as long as you can prove that your test is
equivalent to those on their list.

Tony

{Original Message removed}

2002\08\21@172547 by Tony Pan

picon face
I said:

> Depend on the type of your application, the UL1998 requires you to do
either
> 16-bit or 32-bit CRC.

Actually, depend on the type of your application, the UL1998 requires you to
do either a
checksum, or a 8-bit CRC, or a 16-bit CRC.



{Original Message removed}

2002\08\22@214437 by Peter L. Peres

picon face
On Wed, 21 Aug 2002, Tony Pan wrote:

>>> So what does UL1998 (?) specify ? > 1:2^N where N is the number of rom
>bits you have ? ;-)
>>> Are they saying that 'just testing it' is enough or is there a target
>number ?
>
>Depend on the type of your application, the UL1998 requires you to do either
>16-bit or 32-bit CRC.
>
>If you don't do CRC, you can choose to do other tests on their list. You can
>even come up with your own test as long as you can prove that your test is
>equivalent to those on their list.

Ok, now I understand. I have not read UL1998 (I don't need it - yet).

Are the used CRC algorythms patented by anyone ? Just asking.

Peter

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...