When chips are designed there are often features that are part of the test or not fully qualified. These “improvements” can be leaked or discovered by study and/or serendipity. Sometimes the user discovers something purely because he has a different perspective. But take care before you use this information in production designs: There may be consequences.
In our engineering courses I hope we were all taught not to design to typical specifications, but to use worst case. I remember speaking to a self-taught designer who was complaining that he had been using a particular transistor for several years, changed the transistor manufacturer and his design stopped working. From what I have heard anecdotally, I am sure that was not an isolated incident.
But that is not the undocumented/unguaranteed projects that I was thinking of (note to self: dangling participle — shouldn’t use). New (and not-so-new) graduates may be unaware that there are additional instructions in microprocessor/microcontroller instruction sets. It seems they are added by the designers and then for some reason are not included within the documentation. Occasionally they slip out. Intel’s 8085 famously had a few as did the Z80. They could be very useful but the manufacturers always said that there was no guarantee that they would always be in the instruction set (that is when they admitted to the additional instructions). Back in those days there was also the concept of second sourcing and you could never be sure that the masks would be identical from one source to another. There was also the question if you could use the instruction across the different variants of the processors. Nevertheless many people used the instructions and as far as I know the masks were never changed. They were the lucky ones.
Industrial distributed I/O circa 1994. The conditioning of inputs and outputs was done via plug in modules that you see on the left and right “wings”. The connection to the Arcnet was via the mezzanine board in the centre. Absolute dead centre is the COM20020.
I once designed a system based around the Motorola MC68HC811E2, a variant within the 6811 family of single chip micros. It had been coupled with a Standard Microsystems COM20020 “ULANC” that provided an interface to an ARCNET local area network (LAN). The ARCNET LAN is suited to process control because the message times are deterministic. The Ethernet was not as popular for process control in those days for precisely that reason. At any rate the 68HC811E2 only had 256 bytes of RAM and as you can guess from the direction I am taking, I needed more. The COM20020 has an on-board 2Kx8 RAM which is supposed to buffer the ARCNET messages. Implicit to the data sheet description was that the RAM could be accessed as registered RAM since you could read and write to it. The message protocol that I had created used only a small part of the RAM and so I tried and quite easily managed to use the RAM for my own nefarious purposes.
Then one day the new batch we had made wouldn’t pass the test. It took a while to analyse, but it turned out that Standard Microsystems made a mask change to the chip and my method of accessing the RAM was affected. We managed to find parts from the old batch, and anyway the product was being discontinued so I managed to extricate myself, but I learned my lesson well.
How about you? Have you ever designed using undocumented properties? And have you been caught with your pants down?