Post by thread:[PIC]: What''s "instruction set test"?

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

>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

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

>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

>>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

> >> 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

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_OUTspeffTakeThisOuTinterlog.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

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 <PICLISTKILLspamMITVMA.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}

>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

> 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

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_OUTTakeThisOuTinterlog.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

> >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

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

>> 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}

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.