On Wed, 04 Jul 2007 21:12:07 GMT, "Neil" <neil@chatfield.me.uk> wrote:
>"Rolf Blom" <all.spam@round.bin> wrote in message
>news:f6b1ru$mq6$1@news.al.sw.ericsson.se...
>> I remember one time a (non-PIC) cpu was acting funny, due to an
>> undocumented opcode that got into a corrupted binary.
>> The opcode caused the cpu to start excercising its address bus in a
>> sequential pattern, and the only way out was reset.
>> (A watchdog was in the design, but disabled during initial testing).
>> This undocumented opcode was intended for factory testing of the die.
>> /Rolf
>This is why some flight control computers have exra circuits to detect
>invalid opcodes being presented to the cpu, and cause a power down type
>reset to keep the cpu working (sort of). Only discovered by chance, but
>confirmed by manufacturer as test opcode causing cpu to go into endless
>(ignoring non-maskable interrupt) loop cycling address bus.
>Neil
In the 1970's, practically any microcoded minicomputer had the concept
of reserved instruction trap.
The PDP-11/70 mini was used for routing airline traffic long after the
"best before" date of that system, since the replacements failed
miserably :-).
Paul
Reply by Neil●July 4, 20072007-07-04
"Rolf Blom" <all.spam@round.bin> wrote in message
news:f6b1ru$mq6$1@news.al.sw.ericsson.se...
> I remember one time a (non-PIC) cpu was acting funny, due to an
> undocumented opcode that got into a corrupted binary.
> The opcode caused the cpu to start excercising its address bus in a
> sequential pattern, and the only way out was reset.
> (A watchdog was in the design, but disabled during initial testing).
> This undocumented opcode was intended for factory testing of the die.
> /Rolf
This is why some flight control computers have exra circuits to detect
invalid opcodes being presented to the cpu, and cause a power down type
reset to keep the cpu working (sort of). Only discovered by chance, but
confirmed by manufacturer as test opcode causing cpu to go into endless
(ignoring non-maskable interrupt) loop cycling address bus.
Neil
Reply by Marra●July 2, 20072007-07-02
On 28 Jun, 23:21, "bruno gavand" <bgav...@club-internet.fr> wrote:
I used to work with a bloke that worked on the first PIC when it was
still a TTL breadboard.
I dont remember him ever telling me about undocumented opcodes.
Reply by Spehro Pefhany●July 2, 20072007-07-02
On Mon, 2 Jul 2007 11:43:41 -0400, the renowned "mc"
<look@www.ai.uga.edu.for.address> wrote:
>"BrunoG" <noreply@micro-examples.com> wrote in message
>news:46890733$0$25947$ba4acef3@news.orange.fr...
>
>> Your warning is right, but I'm sure nobody would be foolish enough to use
>> them (if they do something).
>> Just consider my question as pure curiosity.
>
>Come to think of it, how are you going to find out what they do? How much
>of the state of a PIC can you read out?
Some of the PIC16 series (later/more powerful chips) have IS debugging
hardware on-chip which will allow you to read out the current state.
Of course that doesn't directly tell you what the instruction did...
Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Reply by mc●July 2, 20072007-07-02
"BrunoG" <noreply@micro-examples.com> wrote in message
news:46890733$0$25947$ba4acef3@news.orange.fr...
> Your warning is right, but I'm sure nobody would be foolish enough to use
> them (if they do something).
> Just consider my question as pure curiosity.
Come to think of it, how are you going to find out what they do? How much
of the state of a PIC can you read out?
Reply by mc●July 2, 20072007-07-02
"Rolf Blom" <all.spam@round.bin> wrote in message
news:f6b1ru$mq6$1@news.al.sw.ericsson.se...
> I remember one time a (non-PIC) cpu was acting funny, due to an
> undocumented opcode that got into a corrupted binary.
> The opcode caused the cpu to start excercising its address bus in a
> sequential pattern, and the only way out was reset.
> (A watchdog was in the design, but disabled during initial testing).
>
> This undocumented opcode was intended for factory testing of the die.
Familiar 68HC11 phenomenon. I got it once by accidentally assembling an
'HC11 program with an 'HC12 assembler. Same assembly language, different
opcodes!
Reply by mc●July 2, 20072007-07-02
> Your warning is right, but I'm sure nobody would be foolish enough to use
> them (if they do something).
> Just consider my question as pure curiosity.
Yes... it's a way of learning something about how the PIC works, and also
(perhaps) of distinguishing different versions of the same chip.
Reply by BrunoG●July 2, 20072007-07-02
"David T. Ashley" <dta@e3ft.com> a �crit dans le message de news:
96SdnSKQ3PAu_RjbnZ2dnUVZ_qGjnZ2d@giganews.com...
> "bruno gavand" <bgavand@club-internet.fr> wrote in message
> news:46843566$0$21151$7a628cd7@news.club-internet.fr...
>
> a)These may be reassigned at any time by the manufacturer, rendering your
> code unable to run. The reassignment could even be silent, meaning that
> the manufacturer does not change part numbers.
>
> b)The opcode may have effects (in the digital logic) that you are not able
> to detect with the testing you do. For example, it is possible although
> unlikely that one of these opcode might have built into it "clear the
> 'dirty' flag in the 213'th memory cache entry". Point is it may do
> something that you can't detect with the testing you are able to do.
>
Yes I do agree 100% with you for point a)
for point b), you are right too, operation can be hidden to best in-circuit
debugger and to best operator sagacity.
if nothing is detected, the opcode may be a nop in the best case, and for
the other cases I suggest to name it PTM (as "Puts The Mess") if it causes
troubles later.
Bruno
Reply by larwe●July 2, 20072007-07-02
On Jul 2, 10:03 am, "BrunoG" <nore...@micro-examples.com> wrote:
> My goal is to complete the map, even if I have to fill it with NOPs
Finding undocumented opcodes on, say, the Z80 or 6510, was possible
because much of the system state was readable. In a PIC, of all the
godforsaken architectures to research, that isn't true. You have an
exhausting time ahead of you.
You should start by analyzing the opcode from bits 13 down to 8 and
seeing what patterns emerge. You can then make educated guesses about
what to test. But it's a lot of work and of no practical value
whatsoever. If you ever find yourself reverse-engineering code, and
discover that someone has used one of these undocumented opcodes, you
should advertise the fact widely so we can boycott the product,
whatever it is.
Reply by Rolf Blom●July 2, 20072007-07-02
On 2007-07-02 16:07, BrunoG wrote:
> "Don Lancaster" <don@tinaja.com> a �crit dans le message de news:
> 5ej6ekF393sq1U3@mid.individual.net...
>> bruno gavand wrote:
>>> Hi,
>>>
>>> I listed 119 undocumented PIC16 opcodes here :
>>> http://www.micro-examples.com/public/microex-navig/doc/087-pic16-secret-opcode.html
>>> Does anybody here ever tried one of them ?
>>>
>>> Thanks,
>>>
>>> Bruno
>>
>> Undocumented opcodes can cause all sorts of problems if you depend on
>> them.
>>
>
> Your warning is right, but I'm sure nobody would be foolish enough to use
> them (if they do something).
> Just consider my question as pure curiosity.
>
> Bruno
>
>
I remember one time a (non-PIC) cpu was acting funny, due to an
undocumented opcode that got into a corrupted binary.
The opcode caused the cpu to start excercising its address bus in a
sequential pattern, and the only way out was reset.
(A watchdog was in the design, but disabled during initial testing).
This undocumented opcode was intended for factory testing of the die.
/Rolf