Exact match. Not showing close matches.
PICList
Thread
'[PIC]: What's "instruction set test"?'
2002\08\20@102724
by
Tony Pan
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
>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
|
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
>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
>>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
>> 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
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
> >> 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
|
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_OUTspeffTakeThisOuT
interlog.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
|
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.panKILLspam
@spam@VERIZON.NET>
Sent by: pic microcontroller discussion list <PICLIST
KILLspamMITVMA.MIT.EDU>
08/20/02 10:28 AM
Please respond to pic microcontroller discussion list
To: .....PICLISTKILLspam
.....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
>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}>
>
>*****************************************************************
>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
>
>
>
--
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
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
> 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
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_OUT
TakeThisOuTinterlog.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
>
>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
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
>> 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
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
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...