| ??? 10/05/07 05:45 Read: times |
#145442 - Why? Responding to: ???'s previous message |
Kai Klaas said:
Richard said:
I'm not sure what I could safely have done to "stop" anything from operating once RESET was asserted. The only external logic components were two latches (HCT573) and an 'HCT00, along with that DS1232. The 'HCT00 produced the select and enable strobes to the two BBRAMs. Add a new 74AC00 (no 74ACT00!), invert by the help of one of its nand gates the RST signal of MAX1232 and use another nand gate to invert the nAB15 signal. Now feed the inverted RST signal (nRST) and the inverted nAB15 signal (nnAB15=AB15) to another free 74AC00 nand gate to form the nCE signal of U4. Also feed the inverted RST signal and the nAB15 signal (from output of U5A) to another free 74AC00 nand gate to form the nCE signal of U3. Also add a 2k2 pull-up to the RST line of micro and a 4k7 pull-up to each nCE line of DS1230Ys. Kai Why would one want to do that? The purpose of that exercise was to examine the behavior of those MCU's in combination with external memory. I tried several technologies, ranging from AC to LS and 74C, and even tried a mix, but started out with AC00 and AC573's because the DS89C4x0 can run pretty fast, particularly in its fastest external bus cycle mode (page mode 1). I used the 22K pullups on P0 and P2 just to ensure that the whole setup would work with other MCU's as well. The reason I used discrete logic rather than a CMOS PAL or CPLD was so that others, from other countries, perhaps not as readily able to program their logic could build the same circuit if they wished. The goal wasn't to build a perfect circuit, but to see how the MCU and BBRAM interact. The MCU worked properly 5 times out of 6, but every 6 times or so, it would fail to start, and I found that the BBRAM at 0x0000 was corrupted. I didn't check the upper BBRAM's content. The MCU is supposed to STOP when RESET is asserted, AND the BBRAMs have internal logic to sense low Vcc and block writes. The peculiar behavior halted me, of course. There is no point in "helping" a malfunctioning MCU, particularly if all of its lot malfunction in the same way no matter which of its lot is used. I couldn't pin this failure on the Dallas MCU, as a Philips part produced a similar result. That's what piqued my interest. My position is that if 1 of 100 MCU's of a particular manufacture and model fails, or 10 of 1000 fail in the same way, then one should reexamine whether one should use that product at all ... ever. 1% or higher failure rate of a given product is entirely too high. 1 per 100k pieces is more like it! If there's a consistent defect in the way in which the MCU works, one should stop using that type MCU. If there's a consistent problem in the way in which a BBRAM behaves, the same thing applies. The only REAL question really is whether there are ANY 805x's ANYWHERE that function properly at all. If they require additional components to keep them from failing to meet their claimed specifications, something's wrong, and not with the application design. I suspect, however, that something else is going on, and it may be reset-related, possibly involving an interaction between Vcc and RESET. We'll see. RE |
