| ??? 10/04/07 22:04 Modified: 10/04/07 22:13 Read: times |
#145430 - Maybe this answers some questions Responding to: ???'s previous message |
Jan Waclawek said:
Richard Erlacher said:
I've observed that ALE, nRD, nPSEN, and, worst of all, nWR continue to occur after RESET is asserted on the two, (Dallas, and Philips) MCU's that I was using, though I did not pursue the matter at the time. I in http://www.8052.com/forum/read.phtml?id=145271 said: Oh, this is that first experiment you conducted I assume. I always wanted to hear more details about that (and, I would like you to ask you to try a couple of things, if you want to go back to this case).
But, first, you say that you "observed MCU activity during RESET asserted", does this mean that you had tied up a scope both to RESET and some of the RAM signals (say, the most interesting, /CS and/or /WE), and/or VCC; and recorded this activity? Any pictures, perhaps? Well, YES, though, at first, those signals were observed indirectly via the four gates of external logic that I used to generate the select and enable strobes to the BBRAMs. As I mentioned yesterday, however, I didn't get any pictures because it was not a rigorous study. I used two oscilloscopes, one, a 4-channel TEK 2467B and the other, a 2-channel TEK 475A where I was using the single-sweep mode just to detect activity on nWE with the threshold set far enough from where I "thought" it should be set to avoid being influenced by random noise, of which there was, in fact, very little. I later verified this with my TEK 1240 portable logic analyzer, only because it was already at hand, and because I could set various threshold voltages in it on a pod-by-pod basis. At the time, I was interested in the behavior of the BBRAM. At first I was using a Philips P80C31. Imagine my surprise, when the DALLAS MCU, which purports to have its own built-in brownout detector didn't stop operating during the decay of Vcc! This kept me amused and at the testbench (rather than at the bar) for the entire afternoon. Richard Erlacher said: I'm not sure what I could safely have done to "stop" anything from operating once RESET was asserted. You can use the RESET signal to gate /CS of course, but, first of all, it is suspicious that the mcu did not stop memory access upon RESET, so that should be investigated first. Also the memory should be insensitive to any activity below its stated threshold - that's why are you using that very expensive sort of memory at all, isn't it. I'd suspect at first hearing that you don't supply the BBRAM and '1232 from the same supply branch as the mcu - but that's of course only a wild guess without seeing the actual circuit. Can you please post schematics here? Richard Erlacher said:
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. I don't understand what the purpose of the 'HCT00 gates are. Can you please post schematics of that part, too? JW Have a look at http://www.8052.com/users/ric...0PAGE1.pdf That should make it clear what the purpose of the gates is. This drawing is NOT complete, and it's not exactly what was originally wired, as that was done ad-hoc from memory, and this was done a long time ago. This schematic is the same logic, simple as that is, though the pins are different and I've omitted the passives, if any, on the DS1232, including the spst to GND and the rail connections (I don't think there were any passives required ...) The DS1232 was added as an afterthought quite late in the process and didn't help resolve the mysterious behavior. I was using the BBRAM because I wanted to copy the code into EPROM or MCU-based FLASH once I was finshed playing. At one point, I was using a 62C256 rather than a BBRAM, and at another, I had the 62C256 in a DALLAS "SmartSocket". I found that I could read/write the smart-socket, but couldn't preset its content in the same programmer that I used to initialize the DS1230Y. I found that odd! It's probably a programmer software issue. There's only ONE Vcc, as it all came from the same Vcc plane, and there's only one GND, as there's a contiguous GND plane as well. I've not shown the serial interface, as that used the classic MC1488 drivers and 1489 receivers, as I had a bipolar 12-volt supply available. I tried this circuit with a number of different 5-volt supplies, ranging from the very hefty one with which I started, to a wall-wart powered 78M05 in a TO-220 which was also adequate, though its rise and fall times gave rise to the conditions I mentioned. I also tried a number of switchers, ranging from a 50A version from a "retired" T3 multiplexer, to a 1/2-amp "simple-switcher" samaple from NSC. THe results with the varous switchers, including a PC supply, were mixed, due, I suspect, to excessive noise and ripple. Note that all the parts are CMOS, so a clean 150 mA of Vcc should have done the job nicely. I'd forgotten to include that there was also a '245 to isolate the data bus from the memories, as I didn't want to overload the MCU's data bus. There were also 22k pullups on P0 and P2, as I was examining the circuit behavior with different sorts of latches. I also used the same circuit with old Intel and AMD MCU's, discovering that a number of the ones I'd been holding in stock were defective. Those are gone, now. RE |
