Author Topic: Troubleshooting Microprocessors  (Read 8888 times)

0 Members and 1 Guest are viewing this topic.

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
Re: Troubleshooting Microprocessors
« Reply #25 on: December 29, 2019, 05:43:59 pm »
It's safe for the CPU chip, reset is an input. Whether it's safe for whatever drives the reset pin depends on what that is, but there is certainly a way you can force the reset. A safer method is to use something like a 10 ohm resistor to ground, this will limit the current to something reasonable in case a pin is being driven by a low impedance source.
 

Offline bostonmanTopic starter

  • Super Contributor
  • ***
  • Posts: 2707
  • Country: us
Re: Troubleshooting Microprocessors
« Reply #26 on: December 29, 2019, 07:31:19 pm »
When I pull reset low, it causes the address lines to be a continuous 1.xMHz clock pulse, 0 to approx. 3.5v. Although they are not switching states, they do look close to a good unit.
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
Re: Troubleshooting Microprocessors
« Reply #27 on: December 29, 2019, 09:41:37 pm »
The address lines are a pulse but they're not switching states? That's contradictory, are they pulsing or are they just sitting at a fixed voltage?
 

Offline bostonmanTopic starter

  • Super Contributor
  • ***
  • Posts: 2707
  • Country: us
Re: Troubleshooting Microprocessors
« Reply #28 on: December 30, 2019, 12:32:54 am »
See the two pictures I included for a better idea of what I mean.

On a working one, the signals are jumping around (I assume because the scope isn't synchronized to the board). On the broken C64, only half the signals are present (see picture), and with reset held low, the full screen is filled with signals; but they don't jump around.
« Last Edit: December 30, 2019, 12:35:04 am by bostonman »
 

Offline Shock

  • Super Contributor
  • ***
  • Posts: 4423
  • Country: au
Re: Troubleshooting Microprocessors
« Reply #29 on: December 30, 2019, 06:57:03 am »
We didn't have a vacuum de-soldering gun to share between 20 technicians who produced 90 complete commercial games a day including enclosures (stand up or sit down) 5 days a week. Spending more than 15 minutes on a board was not worth it.

My point is that there are two ways to fix this old technology, the fast way with a few simple tools and lots of experience, or the *really* slow way with a workshop full of hitech gear, schematics and every possible aid.

Vacuum desoldering is actually the fast way but you still need experience as it's easy to butcher PCBs if you are impatient. If parts are scarce, expensive or need further testing they also may need to be removed intact.

Perhaps not on company time but I still think it's best to learn proper manual desoldering without ripping out traces. You will a hard time convincing most people that though that schematics and oscilloscopes aren't useful especially on complex repairs.

Soldering/Rework: Pace ADS200, Pace MBT350
Multimeters: Fluke 189, 87V, 117, 112   >>> WANTED STUFF <<<
Oszilloskopen: Lecroy 9314, Phillips PM3065, Tektronix 2215a, 314
 

Offline techman-001

  • Frequent Contributor
  • **
  • !
  • Posts: 748
  • Country: au
  • Electronics technician for the last 50 years
    • Mecrisp Stellaris Unofficial UserDoc
Re: Troubleshooting Microprocessors
« Reply #30 on: December 30, 2019, 07:29:12 am »
See the two pictures I included for a better idea of what I mean.

I have a 54601A scope myself, bought it new in 1994, use it every day and just love it  :-+

Picture is via the RS232 module and some Unix processing.

 

Offline NivagSwerdna

  • Super Contributor
  • ***
  • Posts: 2531
  • Country: gb
Re: Troubleshooting Microprocessors
« Reply #31 on: January 01, 2020, 04:21:25 pm »
might be educational
 

Offline bostonmanTopic starter

  • Super Contributor
  • ***
  • Posts: 2707
  • Country: us
Re: Troubleshooting Microprocessors
« Reply #32 on: January 02, 2020, 07:08:40 pm »
I've kind of run out of ideas and feel maybe I should readdress repairing this in the future as I feel my measurements take me in a loop.

At the moment, any chips I suspect are not in sockets; nor do I have extras to swap (or my other C64 doesn't have those chips in sockets either).

Any chip I suspect is driven by the address bus which goes to several chips. Any other chip that has bad signals is either being told to be bad by the address bus or is the culprit.

Ideally I'd like the ability to freeze the unit so I can measure chips individually (which is how I opened my initial question), however, doesn't seem easy to do.

Per my initial question, trying to measure microprocessors comes down to needing a custom micro to freeze the bus and measure signals?

 

Offline atmfjstc

  • Regular Contributor
  • *
  • Posts: 121
  • Country: ro
Re: Troubleshooting Microprocessors
« Reply #33 on: January 02, 2020, 07:47:21 pm »
You don't need a "custom micro". As others have said before, the best tool for this situation is a logic analyzer. However, you can do without it (as the guy in the video did). A 4-channel scope, even a 2-channel scope could provide enough information to figure out what's going on. It'll just take more work.

I don't mean to sound mean, but I think your real problem here has nothing to do with the tools available. Looking at your posts, I'm not convinced you have done the research and truly understand how the C64 works and what signals to expect. I'm not even sure you understand how buses work. A tool, however advanced, can only make your work easier and faster, but can't do the thinking for you.

Sometimes you can get lucky and stumble your way into a solution without really understanding what's going on. But just as often, you will hit a brick wall.

If I were you, I'd spend a few days researching the 6510, VIC, the RAM/ROM chips, the C64 schematic, what all the pins mean, and how the chips work together. I think you'll find that none of the chips' behavior is really that complicated. And then you'll know exactly what to look for and how to recognize incorrect behavior.
 

Offline bostonmanTopic starter

  • Super Contributor
  • ***
  • Posts: 2707
  • Country: us
Re: Troubleshooting Microprocessors
« Reply #34 on: January 03, 2020, 02:00:01 am »
Quote
I don't mean to sound mean, but I think your real problem here has nothing to do with the tools available. Looking at your posts, I'm not convinced you have done the research and truly understand how the C64 works and what signals to expect.

You're not completely wrong. Generally speaking, I know what a ROM does, RAM, etc... and been around electronics long enough to know about signals. On paper, it's much easier to interpret the signals because a datasheet states which pins need to be high/low to process data.

I do, however, get overwhelmed by the many signals and where to look in order to find the origin of the signal(s). You're correct, maybe I should sit and read the many pieces of information in order to understand the C64 better. When it comes to the microprocessor section of any piece of electronics I've worked on, I always get overwhelmed. I'm also a bit timid because this is my original C64 and not some random piece I bought. So I don't want to hack the board and trying to approach the problem methodically.
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: Troubleshooting Microprocessors
« Reply #35 on: January 03, 2020, 02:20:25 am »
I've kind of run out of ideas and feel maybe I should readdress repairing this in the future as I feel my measurements take me in a loop.
Yes. Sorry to say, but seems you need to learn basics first until you actually understand what you are doing. Looking at "full screen of signals that jump around" do not sound like CPU troubleshooting at all. What you *can* do in this case - find someone with hands-on C64 knowledge to guide your troubleshooting steps according to your (rather limited) level of expertise.
 

Offline bostonmanTopic starter

  • Super Contributor
  • ***
  • Posts: 2707
  • Country: us
Re: Troubleshooting Microprocessors
« Reply #36 on: January 03, 2020, 07:37:08 pm »
Quote
Yes. Sorry to say, but seems you need to learn basics first until you actually understand what you are doing.

Just to clarify, I'm an engineer, just lack microprocessor experience. Any experience was all theory and any hands on was at a minimal.

Upon posting my question, I never thought I'd receive the extensive feedback focusing on the C64 that I did, so I appreciate it. Obviously I learned a bit more than I knew about uprocessors, but still need much more knowledge (and why I posted my question in 'Beginner'.

Many basic questions still exist like how would I sync my oscilloscope to the microprocessor? I'd need to tap off the clock circuit, but not sure if it can drive the scope. So maybe I'd need to build a buffer amp. I have a 64-channel logic analyzer (two actually) that I'm uncertain work; maybe I'll try connecting one of them.

 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: Troubleshooting Microprocessors
« Reply #37 on: January 03, 2020, 07:58:42 pm »
Many basic questions still exist like how would I sync my oscilloscope to the microprocessor?
https://www.testandmeasurementtips.com/the-trigger-function-of-an-oscilloscope/

Quote
I'd need to tap off the clock circuit, but not sure if it can drive the scope.
Clock of CPU is logic level signal as well. Don't measure clock at the crystal terminals. measure at the clock buffer output.

Quote
So maybe I'd need to build a buffer amp.
No. Clock is logic level signal, any scope can show it w/o any buffers. Schematics of the thing will be very, very helpful. Do you have it?

Quote
I have a 64-channel logic analyzer (two actually) that I'm uncertain work
Leave it alone at the moment, 2-channel scope is good enough for basic troubleshooting. When you see that you need more than 2 channels - THEN look for logic analyzer.
[edit] Logic analyzers show only 0 or 1, they do not indicate logic signal integrity which is much more important in your case. So stick with scope.
« Last Edit: January 03, 2020, 08:03:23 pm by ogden »
 

Offline bostonmanTopic starter

  • Super Contributor
  • ***
  • Posts: 2707
  • Country: us
Re: Troubleshooting Microprocessors
« Reply #38 on: January 03, 2020, 08:11:26 pm »
Quote
No. Clock is logic level signal, any scope can show it w/o any buffers. Schematics of the thing will be very, very helpful. Do you have it?

I meant is the clock signal (I know not to take it at the crystal - and I have schematics) capable of driving the impedance of the scope along with the C64 circuit?
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: Troubleshooting Microprocessors
« Reply #39 on: January 03, 2020, 10:28:07 pm »
Quote
No. Clock is logic level signal, any scope can show it w/o any buffers. Schematics of the thing will be very, very helpful. Do you have it?

I meant is the clock signal (I know not to take it at the crystal - and I have schematics) capable of driving the impedance of the scope along with the C64 circuit?
Yes indeed. Clock buffer is one of strongest digital signal source in such devices, it will not even notice 10MOhm scope probe connected. Could you please share URL/link to schematics, if any.
 

Offline Shock

  • Super Contributor
  • ***
  • Posts: 4423
  • Country: au
Re: Troubleshooting Microprocessors
« Reply #40 on: January 04, 2020, 12:50:24 am »
Here is a video showing testing from an almost dead state. Minimizing the board into a basic running state with the dead test cart seems reasonable to me, especially if you have nothing on the screen. If you have a working board to compare the cart on even easier, with the right triggering you should be able to determine exactly what is working and how clean the signals should be between your two boards.

You should have no problem probing the signals with your oscilloscope it won't load it significantly. If you are concerned about the quality of signals compared to the other board you should look at how you are grounding the probe and use the closest ground. Unexpected noise on the power or specific data line requires attention. As you notice in the video a change in voltage level can indicate a faulty component.  In fact not measuring all voltage levels/ripple and ground continuity to all ICs to start with is punishable by death.

In your case don't make any assumptions in your testing or having introduced a marginal fault by accident with the power supply, video and cables. What worked before might suddenly be the culprit until you double check (even if it works on another system). Pays to use two testing methods followed up with measurement to confirm your findings.

For example, the display flickers for you therefore it must be able to work on this system would be an assumption. So if you haven't thoroughly tested the circuitry involved or double checked your changes to the circuit or changes in your testing environment since the last time it was working correctly you need to revisit it.

He mentions at the beginning his ram looks fine but he based that off seeing just activity alone with the oscilloscope. I think there is a large chance however this video covers your problem. Looks like he has the same board revision as well.

Soldering/Rework: Pace ADS200, Pace MBT350
Multimeters: Fluke 189, 87V, 117, 112   >>> WANTED STUFF <<<
Oszilloskopen: Lecroy 9314, Phillips PM3065, Tektronix 2215a, 314
 

Offline bostonmanTopic starter

  • Super Contributor
  • ***
  • Posts: 2707
  • Country: us
Re: Troubleshooting Microprocessors
« Reply #41 on: January 07, 2020, 08:04:15 pm »
I haven't had a chance to watch the video or continue addressing the problem, but I have a question.

Why can't the microprocessor be removed, and a socket be installed that has all the pins either grounded or pulled to Vcc (ignoring the ones that are either a clock in, Vcc in, etc...)? This would allow the entire address and data bus to remain in one state and allow for measuring all the chips to see where issues are.
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: Troubleshooting Microprocessors
« Reply #42 on: January 07, 2020, 09:01:09 pm »
Why can't the microprocessor be removed, and a socket be installed that has all the pins either grounded or pulled to Vcc (ignoring the ones that are either a clock in, Vcc in, etc...)?
No need. If everybody else can find faults w/o replacing CPU with switchers, you can do it as well.
 

Offline Shock

  • Super Contributor
  • ***
  • Posts: 4423
  • Country: au
Re: Troubleshooting Microprocessors
« Reply #43 on: January 08, 2020, 12:10:43 am »
I haven't had a chance to watch the video or continue addressing the problem, but I have a question.

Why can't the microprocessor be removed, and a socket be installed that has all the pins either grounded or pulled to Vcc (ignoring the ones that are either a clock in, Vcc in, etc...)? This would allow the entire address and data bus to remain in one state and allow for measuring all the chips to see where issues are.

If the microprocessor is functional it is the main diagnosis tool (think of it as a multi channel signal generator), but lifting pins and isolating is a troubleshooting technique you can use if required.

Watch that last video and this one as well, both useful as they give ideas on how to sniff out the problem from a similar state. Ignore that bit about the ram not being used by the dead test cart and soldering through hole plated joints (aside from verifying they are still connected). But otherwise the only place he went wrong (shown in the video at least) was a few assumptions based on previous work which weren't that fruitful, checking previous work though is a good idea.

Soldering/Rework: Pace ADS200, Pace MBT350
Multimeters: Fluke 189, 87V, 117, 112   >>> WANTED STUFF <<<
Oszilloskopen: Lecroy 9314, Phillips PM3065, Tektronix 2215a, 314
 

Offline NivagSwerdna

  • Super Contributor
  • ***
  • Posts: 2531
  • Country: gb
Re: Troubleshooting Microprocessors
« Reply #44 on: January 08, 2020, 11:07:34 am »
Why can't the microprocessor be removed, and a socket be installed that has all the pins either grounded or pulled to Vcc (ignoring the ones that are either a clock in, Vcc in, etc...)? This would allow the entire address and data bus to remain in one state and allow for measuring all the chips to see where issues are.
Simplistically it can... and people have built gadgets using 5V compatible technology to tweak the lines and simulate the uP however life gets rapidly more complex.... to reduce costs DRAM was used rather than SRAM and DRAM requires refresh so there will at least be bus contention and in some cases (e.g. Z80) the actual DRAM refresh is done by the uP itself... further video architectures differ but some work asynchronously with respect to the uP and use some bus logic to arbitrate between the uP and the video... your gadget would need to respect that arbitration.  On very simple architectures you could achieve what you are suggesting... in fact it might be fun to try... an Arduino Mega 2560 would be an obvious starting point as it is 5V and has lots of GPIO but you might find yourself tearing your hair out with the number of wires required and then you would get into the land of a custom PCB for an adapter... and... the rabbit hole goes deep.
 

Offline Shock

  • Super Contributor
  • ***
  • Posts: 4423
  • Country: au
Re: Troubleshooting Microprocessors
« Reply #45 on: January 14, 2020, 11:38:25 am »
Made any progress?

Am going to binge watch a few C64 repair videos tonight, I love murder mysteries. You have probably seen this before but checkout the link below. It mentions some books at the end, "Troubleshooting And Repairing Your Commodore 64" by Art Margolis looks fairly comprehensive.

http://retro64.altervista.org/blog/commodore-64-repair-a-quick-guide-on-the-steps-required-to-fix-it/

The second link shows some other tools born of that time period the logic pulser and probe, clip and current tracer (there was also a logic comparator as well). In the logic clip video (he is demoing on a arcade board) you will see him disable the crystal and manually drive the clock with the pulser.

https://www.youtube.com/playlist?list=PL7K-x1E-x5j_XhmMCJg99_BhLusGDCUgT

Aside from the speed of testing on those tools, triggering on an oscilloscope, a function generator and or a logic analyzer replaces those (functionality wise) and some programmers cover the testing of logic. But doing something similar combined with the board running on minimal ICs (if possible) and a dead test cart then comparing to another board seems to be about as low level as you can get for complex issues.

Here is the troubleshooting approach I would take working within your specific rules of minimal board changes:

1. Proper confirmation that power has no issues and the whole board is supplied and grounded.
2. Video has been ruled out (as much as possible).
3. All input is non responsive and known points of failure like electrolytics, temperamental regulators, dry joints, degraded traces, corroded pins or bad sockets have all been addressed.
4. Basic signs of life and signal quality as per the last video I linked or web guides, service manual, datasheets.
5. Low level or minimal config troubleshooting compared to a good board with the dead test cart.
6. Manually testing and observing data lines.
7. In circuit analog signature analysis with a curve tracer in the hope it shows something missed.
8. Then lastly removing and swap testing components to check if you have an obscure IC or board fault.
« Last Edit: January 23, 2020, 12:29:59 am by Shock »
Soldering/Rework: Pace ADS200, Pace MBT350
Multimeters: Fluke 189, 87V, 117, 112   >>> WANTED STUFF <<<
Oszilloskopen: Lecroy 9314, Phillips PM3065, Tektronix 2215a, 314
 

Offline Shock

  • Super Contributor
  • ***
  • Posts: 4423
  • Country: au
Re: Troubleshooting Microprocessors
« Reply #46 on: January 23, 2020, 12:20:50 am »
Here is another 3 videos that show an efficient repair process.





Soldering/Rework: Pace ADS200, Pace MBT350
Multimeters: Fluke 189, 87V, 117, 112   >>> WANTED STUFF <<<
Oszilloskopen: Lecroy 9314, Phillips PM3065, Tektronix 2215a, 314
 

Offline bostonmanTopic starter

  • Super Contributor
  • ***
  • Posts: 2707
  • Country: us
Re: Troubleshooting Microprocessors
« Reply #47 on: January 23, 2020, 03:35:57 pm »
For some reason I haven't been receiving notifications about message updates.

Unfortunately I set this project aside for a bit. Not because I was having bad luck, but initially I began thinking it was an easy fix. I haven't built a workbench yet, so I'm not setup to spread out with test equipment, and a warm basement.

One thing I've learned after years of working on electronics: when an area gets too messy, accidental shorts and damage to the PCB occurs. So I feel it's necessary to clean the area, take a break, and readdress this in a month or two.

As for the eight steps listed above, the video works as I've used other working C64s on the same setup using the same power supply I built. The only thing I've questioned is whether the power supply putting out 4.88V is too low (although it's suppose to be a 5V regulator - and I didn't buy a cheap one).

 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
Re: Troubleshooting Microprocessors
« Reply #48 on: January 23, 2020, 07:59:54 pm »
4.88 is a bit low, it *should* still work assuming that's the voltage at the ICs rather than at the power supply but it's not ideal.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf