| ??? 03/18/06 00:54 Read: times |
#112441 - This is going to be tough Responding to: ???'s previous message |
This definitely sounds like an interesting problem, but I'm left scratching my head...
Kenneth Jennejohn said:
But not in the case of the P87C51M. Using an analyzer, this part never runs the -RD or -WR lines! There is never a sign of activity on an o-scope. Occasionally this part will start an aborted write cycle (-WR starts to go low), and then does nothing, it just hangs dead. Usually it goes through the motions of running the bootloader, with no write cycles to load the code RAM with, then switches to running out of the code RAM, which is random garbage at this point. Accesses are running around 180nS, which is to be expected. The engineer says we need only 95nS per access. Have you done some basic integrity checks? Is your power supply's output clean? Is it actually clean still clean at the chips? Is your ALE free from noise? What happens when the device "hangs dead"? Does the crystal (if used) even stop? Have you tried running any other code besides your desired target application on your new chip while installed in the target board? I'm curious if the new chip is even capable of executing on your hardware platform. Kenneth Jennejohn said:
We switched to a faster PAL (from 15nS to 7nS) to decrease access times, but this didn't help. I connected Vcc to pin 23, which is a No Connect on the Intel part, to give it more power, but that didn't help. Studying the sheet doesn't readily suggest anything. A support email to Philips got a less-than-helpful response: use a different processor. Has a formal timing analysis suggested that you actually need the faster PAL? Faster parts often tend to have powerful drivers with higher slew rates, and those typically cause more EMI, even if they're not operated at maximum frequency. If the design is already electrically marginal, the added noise could be just enough to push things over the edge. There's a reason why Xilinx puts a slew rate control feature on the CPLDs, for example. Kenneth Jennejohn said:
Has anyone successfully done this swap? Any pointers or tips? Has anyone else tried this and failed and would like to share what they tried so no one else has to repeat the same failing steps?
Thanks for your attention, Kenneth Jennejohn Gallup/Lantek That's the problem with your post. You've only given enough information such that only someone who is intimately familiar with the new chip you're using is going to be able to help you. You've told us very little about the design, which has a very particular, intricate problem. Since we're not sitting at your bench, with your hardware, instruments, and documentation at hand, you have to share more if you want a reasonable shot at a resolution on this forum. Erik Malund said:
P87C51M ??
still Intel? link to datasheet? Access times run around 360 nS. access to code RAM? to pin 23, meaningless when you do not identify the package (better use pin names than numbers) Erik I did a bit of digging, and I'm guessing that he's using one of the devices described in the P87C51MB2/P87C51MC2 data sheet. So, this device is apparently only available in PLCC-44 packages, and pin 23 is an "NC" pin which may alternatively be used as a second VDD line. The use of the extra supply line is a good idea, although I don't particularly like the nomenclature of referring to a pin connected to a supply rail as "NC". And that brings up another few questions. Have appropriate decoupling capacitors been used? Does the PCB contain a ground plane? A VCC plane? Once again, I'm wondering if this board is electrically marginal and the 'MX is pushing it over the edge. Erik Malund said:
a lot of chip substitutions have been unsuccesful because !EA was floating
Erik Indeed. And that's got me wondering what the reset generation circuit is like. It sounds like there might be some additional reset logic present in this system, which could present a problem if not properly designed. --Sasha Jevtic |
| Topic | Author | Date |
| Problem using 87C51Mx as drop-in replace | 01/01/70 00:00 | |
| still Intel? | 01/01/70 00:00 | |
| just a thought | 01/01/70 00:00 | |
| This is going to be tough | 01/01/70 00:00 | |
| Why MX? | 01/01/70 00:00 | |
| Problem using 87C51Mx as drop-in repla | 01/01/70 00:00 | |
| I tend to recall that the MX has some ER | 01/01/70 00:00 | |
| I tend to recall that the MX has some E | 01/01/70 00:00 | |
| if time permits. | 01/01/70 00:00 | |
| Engineers ? | 01/01/70 00:00 | |
| Very true! | 01/01/70 00:00 | |
Thanks Erik but don't bother... | 01/01/70 00:00 |