Hi All,

A continuation of another thread that got a wee bit off topic.

Chuck (Night Driver) wrote:

I hate to drag this discussion back (NOT but i have enjoyed it) Cherie's post for a bit but (s)he refrred to reading the schematic as the best way to handle hardware,and that testing was for the less capable (paraphrase mine) and that embedded systems/chips was truly a strawman. If memory serves, we have had a few of the folks who wrote firmware for embeddeds, as well as a few folks who designed operations which included embeddeds and all of them have suggested that reading the specs etc will NOT give a usable answer as the chip actually used may vary from batch to batch and the schematics/specs may not match this batch.

I've done some embedded work (about 20 years, on and off) and for most small embedded systems, reading the schematics won't tell you much of anything. All you'll see are connections between standard devices, but how the devices are used is determined by the firmware.

In some cases, the same schematic can be used to implement widely varying behavior, depending on the firmware and where the board's installed (current 'stamp' boards and PIC chips are like this -- generic boards/chips where the I/0 lines can mean different things depending on firmware).

Also, I've done several designs where the same firmware was used, but the actual CPU chip could change depending on price and availability. The functions needed by the firmware were the same on several chips in a mfgr's line of CPU's, and the extra baggage on each different chip (A/D converter, date processing, keypad input, etc.) was ignored.

The question of specs normally addresses what an embedded system is supposed to do, not the extra things that could be hanging around. That is, if an embedded system uses a CPU that has date processing capability, but date processing isn't used, the spec neglects to mention that (because it's not part of what's needed -- it's a freebie on the CPU).

Testing is absolutely required to know if an embedded system will work come 1/1/00. Nothing replaces testing.

BUT ... the systems with unused, but present, date processing capability CANNOT BE TESTED. The internal date logic is merrily ticking away, but there's no way to test it because the code to access the date hardware is not in the firmware. This type of date situation could malfunction (if it's going to) at any time after 1/1/00, maybe years later.

-- Dean -- from (almost) Duh Moines (dtmiller@nevia.net), March 08, 1999

Answers

This topic has been debated before on many groups, but I'd still like to see an answer.

1. If the date logic in a CPU (just ROM code that accesses the clock, presumably) is unused, then how can it crash the firmware?
2. If there's no interface for setting the clock, why would it crash at 1/1/00? It's just as likely to have been initialized to 1/1/80 or whatever at powerup, leaving 20 years of continuous operation before failure. Some people seem to think the clock is carefully set in the factory and the time maintained via backup battery all through the manufacturing and installation process. Hard to believe.

-- Michael Goodfellow (mgoodfel@best.com), March 08, 1999.

" the code to access the date hardware is not in the firmware. " " there's no way to test it " Dean; I have been seeking an understanding of this issue for over a year. Do you have any guesstimate about the fraction of embedded ststems that may be afflicted with this vulnerability? Thank you for the clarification. Best regards,

-- Watchful (seethesea@msn.com), March 08, 1999.

Hi Dean, yea I guess we did get a little off topic ;) I, and many of us, also would like as much info on this issue that you can give us. If a clock is a freebie and no code is using it, wouldn't it just roll over to 0 when it maxes out? Just one of many questions. Thanks in advance for any help you can give us. <:)=

-- Sysman (y2kboard@yahoo.com), March 09, 1999.

'Bend or break!'........Solution!!!!!!! Ommmmmmmmmmmmmm.......

-- Outlander (godsgold@hotmail.com), March 09, 1999.

embedded systems that will be affected by the y2k problem will be systems that require monitoring in real time conditions.The embedded system needs to handshake with the host system and give a real time account of a status and or failure conditions such as mr/h count of an enviroment around a nuclear reactor or sensors monitoring real time flow of water,chemicals or oil thru a pipe line. These systems run independent of the host computer so that if the host goes down it does'nt have to bring down the embedded system that falls back to fail safe operation so it can prevent full scale failure and environmental release.

This type of operation is widely used so after a host failure critical operational data is not lost when the host computer comes back on line. These embedded systems use real time clock features that do include a year field that sometimes can be accessed by the host and changed and sometimes it is not acessable. Because it is burned in by the vendor and keep out of reach of the customer on purpose to prevent the customer from acessing propietary firmware. This means that the customer has to go back to this vendor to fix or modify a system.

In most cases when a system is designed, a set of specs is issued from a company's design team to a vendor for prototyping to get it operational then they send it to another to build the production run. This is the case in highly classified Government and Corporate projects. Many times the company who builds it does'nt always know every thing that is designed into it to make it work. They are just given a broad set of test spec's if the system passes its not looked into any further. With y2k you need specific tests designed by systems designers to ferrit out hidden y2k sensitive operations embedded in the firmwares structure. They are alot of systems that will be y2k sensitive.

-- y2k aware mike (y2k aware @ conservation.com), March 09, 1999.

Hi guys,

[wow, the formatting on my original message sure didn't come out right]

Y2k aware mike has one of the major problems right when he says that embedded systems are built and tested to spec -- and who knows how they get used by the people ordering the part.

Mike Goodfellow asks how unused date functions get initialized. I have no idea. :) If they're unused, they may be initialized at zero or may have a random date. I don't recall what the manual said (it was 15 years ago for that design and I didn't pay attention to the date functions).

Sysman wants to know what happens when an *unused* date function rolls over. Depends. It would depend on whether or not the date registers use memory accessible to the engineer, or a separate memory. If it uses addressable memory, then it's possible (I don't know how likely) that instead of rolling over to 00, it rolls over to 100, using an extra nibble (4 bit memory location). If this location was used by the engineer for another purpose, something gets messed up. How likely is this to occur? Your guess is as good as mine.

Some chips do have the date set at the factory, but (I would assume as I haven't checked) these chips would have some way of staying powered until installation.

Chips need exceedingly little power, especially if only a date function is running (a counter not needing the CPU). (I'm currently wearing a quartz controlled wristwatch with a mechanical, not LCD, movement. It has no battery, rather it's light powered -- 5 solar cells, each 2x4 mm in size will charge up a capacitor enough to run the watch in the dark for 30 days. Extremely little power is used.)

Watchful asks how many embedded systems might use CPU's with unused, but active, date functions. Again, there's no way to know.

In the example I gave, there were three chips (as I recall) that could be plugged into the circuit interchangably and provide the needed functions. One of these chips had a date function (unused) and the other two chips had other unused, on-chip functions. The decision about which chip to use was made entirely by purchasing and production -- it depended solely on the chip price at the time of production. And purchasing had no idea what unused functions were on each chip, they went by part numbers.

-- Dean -- from (almost) Duh Moines (dtmiller@nevia.net), March 09, 1999.

To answer how a date is initialized in a chip, let me pose this question. How does Intel put a unique identification number into each Pentium 3? The same method of "burning" data into a chip is used for both and it's done during the first power-up and test of the chips as they move down the production line. The timestamp is part of the production batch data. Which is in turn, part of the serial number that Intel got into trouble for announcing the capability to trace. The production timestamp is the chip "creation date" or "default date" which is used if there is no user inputted date and time.

And there are chips which use either small, internal capacitors or lithium cells to keep the time calculations running. These power sources are located inside the chip case and are recharged by the chip's external power source when the chip is turned-on.

As far as Intel's capabilities to ID individual chips, I was involved in building and testing the machines that Intel is using to test and download the IID data *and date/time information* to new chips. I'm surprised that all the major chip makers aren't or haven't been ID- ing their products for some time now. This isn't something brand-new, just maybe easier to do on a chip-by-chip basis.

WW

-- Wildweasel (vtmldm@epix.net), March 09, 1999.

We have a farmer who operates a large lemon operation here. He tested, incooperation with the local power company to see if his farm is Y2K Compliant. He was (Jan 1997!) Three days later, the bank of pumps that was irrigating the orchard REFUSED to start! To make a long story short, large equipment users must allow the electric company some control so that power can be restored after a blackout. The chip is "so stupid" it does not return to ZERO STATE when it encounters a negative number! Those power controller boards FROZE and had to be thrown away.

The farmer, who stopped computer programming in the mid '80s to farm, said that embedded chip is used in hospitals, large apartments, office buildings, etc. The chip was redesigned in 1988 just after the 20 wear building boom ended.

The HVAC systems in most buildings built 1972 to 1988 are vulnerable.

-- Kev Stevens (Lurker123@yuma.farm.com), March 09, 1999.