I've encountered stuck uP's (micro lockout we used to call it) many many times over the years in TV's VCR's, audio gear etc. Even remotes.
The 'big chip' is probably the most reliable part in there 😉 but they can lock up. I can give examples where the problem isn't even fixed by removing power for a few hours, the thing has to be left for several days for internal charge to dissipate.
There's no doubt this type of lock-up occurs, as you quite rightly point out. I was referring more to the result of poor coding practice where corrupted variable values (e.g. option / parameter data stored in non-volatile memory) can cause unexpected code execution in some circumstances.
If the PDT line is not being pulled low externally by Q506 and associated circuitry, as measurements might reveal, I wouldn't mind betting that the PDT line is being controlled by 'runaway' code in the processor. Port 8 pins on that CPU can also be configured as outputs (normally, the pin associated with PDT is configured as an input in this application). Just a thought 😉
Last edited:
Hi,
Maybe I am missing something but you do not mentioned if the relay click when the power it is applied. Do you heard the relay clicking when power it is applied?
Maybe I am missing something but you do not mentioned if the relay click when the power it is applied. Do you heard the relay clicking when power it is applied?
It's not that straightforward unfortunately. The power relay is controlled by the main microprocessor, which is also responsible for controlling many other aspects of the amplifier. The issue at the moment is in getting the microprocessor to boot properly before it can issue the relay signal.Hi,
Maybe I am missing something but you do not mentioned if the relay click when the power it is applied. Do you heard the relay clicking when power it is applied?
r0k1e, have you tried Mooly's suggestion (post #16) of discharging the storage capacitors on the back-up supply rails?
Last edited:
Yup, no relay click as I've mentioned in the startpost...
I'm going to try Mooly's suggestion after re-checking PDT related voltages. Thanks folks for guiding me!
I'm going to try Mooly's suggestion after re-checking PDT related voltages. Thanks folks for guiding me!
Hi,
The relay should be enable. The micro it is telling by the PRY signal to enable the relay. The base of Q311 it has 4.8 volts. That would enable the transistor. The collector of Q311 should be +12 volt and it will applied +12 to the base of Q315. One side of the relay has +12 and zero at the other side by the Q315. That relay should be enable. When the relay it is enable it will applied 120 AC volts to the accessories outlets. You should read 120 volts at the outlets if the relay it is closed.
The relay should be enable. The micro it is telling by the PRY signal to enable the relay. The base of Q311 it has 4.8 volts. That would enable the transistor. The collector of Q311 should be +12 volt and it will applied +12 to the base of Q315. One side of the relay has +12 and zero at the other side by the Q315. That relay should be enable. When the relay it is enable it will applied 120 AC volts to the accessories outlets. You should read 120 volts at the outlets if the relay it is closed.
So those voltages are accurate and refer to PDT = 0.13V. I know that looks very strange. I even replaced R674 to be sure, but it didn't help. Looks like PDT is shorted to ground somewhere inside uP after ~2 minute delay.1) +MB 13.7V
2) Voltage across zener, D503 0V (Anode), 6.52V (Cathode)
3) Q506 E,B,C 13.71V E, 13V B, 13.66V C
4) R663 - R673 junction 7.15V
To follow Mooly's suggestion to remove all charge from back-up rails +5M1 and +5M2 I left C662 "+" connected to ground via 100 Ohm resistor and C660 "+" via 150 Ohm. No result after 1 hour. About 50 mV on +5M1 remained. Will wait longer.
Maybe I should connect the unit chasis with PE from outlet for faster draining?
tauro0221,
Red values are from service manual. Green are what I actually measured.
Hi,
OKAY. I download the schematic. The PRY signal it is coming from th micro pin 115. It is an output pin. Normally in the way MICRO it is reset is on powered ON the reset pin it is hold down for a few seconds to allow the VCC to settle down. Then in the transition from zero to high the micro it is reset. One way to check if the micro will re-start is on power ON wait for few seconds and then ground the reset pin and the micro should start run. The reset pin should be normally high after power ON.
OKAY. I download the schematic. The PRY signal it is coming from th micro pin 115. It is an output pin. Normally in the way MICRO it is reset is on powered ON the reset pin it is hold down for a few seconds to allow the VCC to settle down. Then in the transition from zero to high the micro it is reset. One way to check if the micro will re-start is on power ON wait for few seconds and then ground the reset pin and the micro should start run. The reset pin should be normally high after power ON.
Hi,
On thread 28 you said that the voltage at pin 27 should be high and the reading is .13v. The voltage at resistor R673 read is 7volt. Means that something it is loading the signal down between R673 and R674 or the connection it is open between the resistors and pin 27. There are also 2 possibility that the micro is not running or the input pin was damaged causing to load down the input signal. The first thing you do when programming a micro at start up it is the conditioning of the pins as inputs or outputs. If you do not set the pins as a input it will load down the input signal. Normally the pins are set to outputs. One test to check it is power down, wait until all voltage discharge then read the resistance between pin 27 and ground. A low resistance reading means the input it is shorted or still exist the possibility that the micro is not running.
On thread 28 you said that the voltage at pin 27 should be high and the reading is .13v. The voltage at resistor R673 read is 7volt. Means that something it is loading the signal down between R673 and R674 or the connection it is open between the resistors and pin 27. There are also 2 possibility that the micro is not running or the input pin was damaged causing to load down the input signal. The first thing you do when programming a micro at start up it is the conditioning of the pins as inputs or outputs. If you do not set the pins as a input it will load down the input signal. Normally the pins are set to outputs. One test to check it is power down, wait until all voltage discharge then read the resistance between pin 27 and ground. A low resistance reading means the input it is shorted or still exist the possibility that the micro is not running.
No luck after leaving it discharging overnight... Found it behaving same after plugging back into AC - good +MB, PDT, but no PRY. PDT sagged to 0.13V a bit after. Soldering everything back to try again and wait even more...
tauro0221,
Thanks for the hint! I will check pin 27 (PDT) - Ground resistance level. And already tried to pull down /RES by sgrossklass suggestion. It didn't make uP generate PRY, see post #11
tauro0221,
Thanks for the hint! I will check pin 27 (PDT) - Ground resistance level. And already tried to pull down /RES by sgrossklass suggestion. It didn't make uP generate PRY, see post #11
This would tend to confirm my suspicion that the microprocessor is not executing the correct firmware code, for reasons yet unknown. Either the CPU is unable to read its associated ROM code correctly, or it is extracting invalid data from its backed-up memory. Refer to my post #21, second paragraph. It doesn't necessarily indicate that something is wrong with the CPU. The CPU is simply instructing the PDT pin to switch modes from being that of an input, to that of an output with its output being set at a logic 0.So those voltages are accurate and refer to PDT = 0.13V. I know that looks very strange. I even replaced R674 to be sure, but it didn't help. Looks like PDT is shorted to ground somewhere inside uP after ~2 minute delay.
While the /RES pin is held low, all configurable port pins on the CPU are normally forced to be inputs and that explains why the PDT line starts off at 4.5V and then later changes to 0.13V as the CPU executes 'extraneous / invalid' code after a minute or so. So all is not yet lost!
As you have already followed Mooly's capacitor discharge suggestion, check that the CPU reset pin is being correctly controlled if you haven't already done so: With a voltmeter (or, preferably an oscilloscope) on /RES of the CPU, check that the voltage at switch-on rises to about 4.5V and then drops to (nearly) 0V almost immediately. About a second (or so) later, /RES should return to about 4.5V.
If, the above all appears normal and the CPU still doesn't correctly boot the next areas to explore would be:
- Check that the ROM IC is receiving a valid power-on reset. IC 527 pin 12 connects to pull-up resistor R616 and C591 to 0V. It is vital that the reset pulse at pin 12 of the ROM occurs and returns logic high before the CPU /RES line completes its own reset. Is C591 and/or R616 faulty?
- Check that the voltages on the ROM pins appear to follow those shown in the service manual.
- Check the continuity of all the address and data lines between the ROM and CPU. A hairline break in just one of these lines would prevent correct CPU operation. Labourious, but if you check each one and cross them off on a copy of the schematic as you go, you can at least rule out this possibility.
Good luck!
Last edited:
It looks like the µP does something for a while, until it goes into some weird latched-up state. (Note that voltage on PDT = SDTN is given as 0V in operation, but that might be a mistake.)
A few theories on what might be happening:
1. Processor is working but unstable, e.g. because voltage regulator is oscillating. I'd check/replace C645 then. Got some freeze spray to try on the 5V regulator, to see whether things keep working for a longer time then? Or just anything cold, really? These NJR regs can be a bit unreliable at times.
2. Processor works but receives conflicting/wrong information e.g. from protection. How's it looking on the other inputs?
3. Processor programming or logic is somehow partly b0rked. EDIT: See ROM troubleshooting, above. I thought it would be a simple OTPROM job, but flash ROM complicates things.
What you could still try is splitting the PRY connection and applying 5V there yourself (hard-wired or shortly after mains power is applied) to see whether she springs to life then.
A few theories on what might be happening:
1. Processor is working but unstable, e.g. because voltage regulator is oscillating. I'd check/replace C645 then. Got some freeze spray to try on the 5V regulator, to see whether things keep working for a longer time then? Or just anything cold, really? These NJR regs can be a bit unreliable at times.
2. Processor works but receives conflicting/wrong information e.g. from protection. How's it looking on the other inputs?
3. Processor programming or logic is somehow partly b0rked. EDIT: See ROM troubleshooting, above. I thought it would be a simple OTPROM job, but flash ROM complicates things.
What you could still try is splitting the PRY connection and applying 5V there yourself (hard-wired or shortly after mains power is applied) to see whether she springs to life then.
Last edited:
Note that PDT is an input (Power Down Detect to the CPU) and is not related to SDTN according to the schematic. PDT sits at +4.5V in normal operation. SDTN is serial data output from CPU that connects to IC610 (video overlay) on the video board.It looks like the µP does something for a while, until it goes into some weird latched-up state. (Note that voltage on PDT = SDTN is given as 0V in operation, but that might be a mistake.)
A few theories on what might be happening:
1. Processor is working but unstable, e.g. because voltage regulator is oscillating. I'd check/replace C645 then. Got some freeze spray to try on the 5V regulator, to see whether things keep working for a longer time then? Or just anything cold, really? These NJR regs can be a bit unreliable at times.
2. Processor works but receives conflicting/wrong information e.g. from protection. How's it looking on the other inputs?
3. Processor programming or logic is somehow partly b0rked. EDIT: See ROM troubleshooting, above. I thought it would be a simple OTPROM job, but flash ROM complicates things.
Faulty (oscillating) regulators and processors don't mix well indeed! If the regulator was oscillating, I would perhaps expect to see a random pattern occurring in the CPU startup. However, the OP reports that it 'reliably' goes into a defined mode after a minute. Saying that, it wouldn't do any harm to check that the regulator is giving a clean output.
Even if PRY was manually applied, which should power up the amplifiers, the main CPU would still not be operating normally. Until the PRY line has been asserted and a period of time elapsed to allow the output amps to stabilise, the state of the protection circuitry is meaningless and the CPU should ignore these initially. Because the main CPU controls so much of this amplifier, it needs to work before anything else.What you could still try is splitting the PRY connection and applying 5V there yourself (hard-wired or shortly after mains power is applied) to see whether she springs to life then.
No luck after leaving it discharging overnight... Found it behaving same after plugging back into AC - good +MB, PDT, but no PRY. PDT sagged to 0.13V a bit after. Soldering everything back to try again and wait even more...
It was certainly worth a try.
When faced with something like this, my line of attack was to go around every pin (yes every pin) with a DC coupled scope and to make sure that what was present seemed reasonable.
Was there some doubt earlier over the internal clock perhaps running not correctly ? That has to be up and running 24/7
Hi,
Troubleshoot this problem would be more easy if you have an scope. You can check the program memory address pin for pulses means that the micro it is running at powered up. I think that the first thing that the micro check it is the PDT to see if the VCC it is OKAY then it will enable the PRY. In thread 12 you showed that the voltage pins for the clock are 4.8v and the schematic showed that it should be 2.3v and 2.2v. It is possible that the clock it is not oscillating. The only way to verified it is by checking the memory address pins for pulses.
I do not know why the used flash memory. They can loosed the data easily compared with the proms memory.
Troubleshoot this problem would be more easy if you have an scope. You can check the program memory address pin for pulses means that the micro it is running at powered up. I think that the first thing that the micro check it is the PDT to see if the VCC it is OKAY then it will enable the PRY. In thread 12 you showed that the voltage pins for the clock are 4.8v and the schematic showed that it should be 2.3v and 2.2v. It is possible that the clock it is not oscillating. The only way to verified it is by checking the memory address pins for pulses.
I do not know why the used flash memory. They can loosed the data easily compared with the proms memory.
First of all, thanks guys for being so helpful and detailed!
The good news is that I've picked up a scope! Now it gets even more interesting 🙂
So for /RES behavior, I was able to see a momentary drop (or two, very fast) to 0V and back to 4.8V immediately (not after 1 second).
Service manual, however, confuses me:
In my case, /RES is ~2V when AC cord unplugged and 4.8V shortly after AC cord is plugged in...
Anyway, now I'm able to check that oscillating signal from XL501. Here's what I saw (DC mode, 100nS):
https://www.youtube.com/watch?v=2wCdNMk74SA
And the reference image from Service Manual:
That gives me an assumption that the oscillator doesn't work properly (significant DC component where it's not expected to be at all). Could it be bad XL501 resonator? Or it indicates uP problem? The video was captured for the case when XL501 expected to be working (voltages are 2.45 0 2.28). Once it goes to 4V level after a while, I see no AC component at all.
And then further I decided to check IC527 flash ROM pins and here's what I saw for pin 1-5 (similar meander-alike signal, just a different frequency):
https://www.youtube.com/watch?v=cgoJaK0BsPk
After 2 minute delay I see no oscillation and following voltages:
Pin (Voltage, Volts)
1 (4.9)
2 (0)
3 (0)
4 (0)
5 (0)
Datasheet says those are Address Inputs. Not sure what should I observe on them...
For 5V voltage regulator, I don't see any oscillation on its output. There's some on +MB though. I can still try to change it and related capacitors.
For PDT-ground resistance, it's 4.7 KOhm, so OK.
The good news is that I've picked up a scope! Now it gets even more interesting 🙂
So for /RES behavior, I was able to see a momentary drop (or two, very fast) to 0V and back to 4.8V immediately (not after 1 second).
Service manual, however, confuses me:

In my case, /RES is ~2V when AC cord unplugged and 4.8V shortly after AC cord is plugged in...
Anyway, now I'm able to check that oscillating signal from XL501. Here's what I saw (DC mode, 100nS):
https://www.youtube.com/watch?v=2wCdNMk74SA
And the reference image from Service Manual:

That gives me an assumption that the oscillator doesn't work properly (significant DC component where it's not expected to be at all). Could it be bad XL501 resonator? Or it indicates uP problem? The video was captured for the case when XL501 expected to be working (voltages are 2.45 0 2.28). Once it goes to 4V level after a while, I see no AC component at all.
And then further I decided to check IC527 flash ROM pins and here's what I saw for pin 1-5 (similar meander-alike signal, just a different frequency):
https://www.youtube.com/watch?v=cgoJaK0BsPk
After 2 minute delay I see no oscillation and following voltages:
Pin (Voltage, Volts)
1 (4.9)
2 (0)
3 (0)
4 (0)
5 (0)
Datasheet says those are Address Inputs. Not sure what should I observe on them...
For 5V voltage regulator, I don't see any oscillation on its output. There's some on +MB though. I can still try to change it and related capacitors.
For PDT-ground resistance, it's 4.7 KOhm, so OK.
Hi,
The pulses at the memory pins means that the micro it is addressing the memory and the micro is running. Now, Looking at the picture for the reset signal I do not see a pulse. It should be at the leading edge of the +MB. You should see a nice pulse. The pulse it is generated by the capacitor C633. Can you check the pulse signal before and after the capacitor C633 and post the scope picture? Just to eliminate the power switch can you check that when you enable/disable the power switch the pin 26 change from 0 to +5. This is to verify that the power switch it is working.
The pulses at the memory pins means that the micro it is addressing the memory and the micro is running. Now, Looking at the picture for the reset signal I do not see a pulse. It should be at the leading edge of the +MB. You should see a nice pulse. The pulse it is generated by the capacitor C633. Can you check the pulse signal before and after the capacitor C633 and post the scope picture? Just to eliminate the power switch can you check that when you enable/disable the power switch the pin 26 change from 0 to +5. This is to verify that the power switch it is working.
First of all, thanks guys for being so helpful and detailed!
The good news is that I've picked up a scope! Now it gets even more interesting 🙂
So for /RES behavior, I was able to see a momentary drop (or two, very fast) to 0V and back to 4.8V immediately (not after 1 second).
In my case, /RES is ~2V when AC cord unplugged and 4.8V shortly after AC cord is plugged in...
Having an oscilloscope will be a great advantage 🙂
The reason you're seeing ~2V on the reset line is due to the charge on the super-cap, C662 when the unit is unplugged from the mains. I would try replacing C633 (0.47uF / 50V) to see if that results in a longer reset pulse. If you don't have that exact value, a 1uF (10V minimum) electrolytic could be temporarily fitted.
Last edited:
- Status
- Not open for further replies.
- Home
- Amplifiers
- Solid State
- Yamaha DSP-AX2 no signs of life.