Herbert Graf wrote: > To each his/her own I suppose. You're right, I haven't been > burnt, which is what gives me a unique alternative point of view. > > All indications in the errata point to this flaw easily being > caught in "proper" testing, therefore testing which DIDN'T catch the > flaw is obviously flawed itself. True, but then again all testing if flawed in some way by that definition. In most cases it is impossible to reproduce all conditions during testing. Even when it is theoretically possible, it is usually prohibitively expensive. So in the end you do the amount of testing that is warranted given the price of the product, its volume, and the cost of a failure. When I'm developing firmware for a customer, I of course perform tests to make sure the firmware reacts as it should in as many ways as is reasonable. In addition, I use knowledge of its structure to test it in ways that exercise different blocks of code. I want to make sure the customer gets used to when we release code, it "just works". However, we don't test specifically looking for devices not performing to the manufacturers specifications, and we certainly don't test over the full range of environmental conditions unless the customer specifically asks for (and pays for) this. This kind of testing can be quite expensive, and is not done in the vast majority of products. The problem with the 18F1320 is a good example. I discovered the problem during debugging. The first symptom was that the unit wouldn't respond to serial commands, although the conditions that caused this seemed to be unpredictable. Naturally I didn't start out suspecting the chip. If I remember right, it took over a day on a fixed price job to track down this problem. Eventually I could show that everything worked right when run at 20MHz, but not a 40MHz. (Unfortunately 40MHz was needed to do all the processing, so I had to switch to a 18F252 all for the same fixed price). Note the lurking problem here. Suppose the project only needed 20MHz in the first place. Everything may have appeared fine on my bench and in the customer's hands, but 1 in 100 could have a flaky problem in the field. Or maybe 1 in 10 flake out at higher or lower temperature. The point is that reasonable testing regimes given the nature of this product might not have uncovered the PIC not performing to specifications. Except in extreme cases perhaps, who is reasonably going to spend the money worrying about a PIC failing at 20MHz when it's rated at 40MHz? In all cases I've ever worked on that would be considered a generous margin. Since March I had been considering the 18F1320/1220 20MHz devices. I even labeled the drawers they were in with "20MHz" to make sure they didn't accidentally get used at higher speed. I didn't know either until yesterday that in fact they were only 4MHz devices. I knew there was a speed problem. I had seen it at 40MHz and 32MHz but not at 20MHz. 2:1 seemed like enough margin. It's only by pure luck that I didn't use one of these chips at 10MHz in some project. It's not clear to me at all that reasonable testing would have uncovered at problem at 10MHz with the one or two units I might use during testing and debugging. ------------------------ By the way, I was not sure what Microchip's reaction would be when I told them their chip didn't run at full speed. I was expecting a lot of skeptisism and a response like "Yeah, yeah, let us know when you think the sky is falling too". To their credit and my great relief, my local FAE took me seriously right form the start. He gave me a PICdem board I could put a test case on, and made sure it got sent to the right person in Arizona. About a month later I got confirmation that the engineer in Arizona could reproduce the problem and agreed there was definitely something wrong with the chip. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.