EEVblog Electronics Community Forum
EEVblog => EEVblog Specific => Topic started by: EEVblog on January 31, 2015, 09:15:23 pm
-
Join Dave step-by-step as he attempts to find the problem with a non-booting Aiphone GF NS building intercom system. Will a reset chip make a monkey out of him?
And as always, a trap for young players is explained.
Brochure:
http://www.zsing.com/download/aiphone/gf-k.pdf (http://www.zsing.com/download/aiphone/gf-k.pdf)
Install Manual:
http://www.aiphone.net.au/media/GFNS_Install.pdf (http://www.aiphone.net.au/media/GFNS_Install.pdf)
Setup Manual: http://www.aiphone.com/home/assets/Uploads/downloads/documents/products/instructions/GF-NS%20Progr%20Instr.pdf (http://www.aiphone.com/home/assets/Uploads/downloads/documents/products/instructions/GF-NS%20Progr%20Instr.pdf)
Datasheets:
Mitsubishi M16C: http://pdf.datasheetcatalog.com/datasheet/MitsubishiElectricCorporation/mXuuxwr.pdf (http://pdf.datasheetcatalog.com/datasheet/MitsubishiElectricCorporation/mXuuxwr.pdf)
24LC128 EEPROM: http://ww1.microchip.com/downloads/en/DeviceDoc/21191s.pdf (http://ww1.microchip.com/downloads/en/DeviceDoc/21191s.pdf)
RS232 driver: http://www.ti.com/lit/ds/symlink/ds14c232.pdf (http://www.ti.com/lit/ds/symlink/ds14c232.pdf)
EEVblog #710 - Intercom System Repair (https://www.youtube.com/watch?v=-MKUsLi90O4#ws)
-
Are you SURE the original 10K resistor is not to GROUND?
i.e. 10k keeps RESET low, reset uC drives it high when 5v rail is above brown out voltage!
Hence, removed reset uC = RESET (cause 10k pulls reset low) and 100R mutimeter to 5v brings line high (Vreset is 5v * 9.9/10)
You swapped resistor to 1K, 100ohm still just enough to get out of reset (Vreset is 5V * 900/1000)
Then fitted 270ohm, now, of course your 100Ohm "mutimeter shunt" isn't enough, and you need 30Ohms!!
Check this!!!
PS, units current has gone up because you have a 270Ohm short to ground!
-
As annotated in the video, this sounds like classic SCR latchup, especially with such a messy 5V rail. Older type chips (and I really mean type, this chip is probably made on absolutely ancient .35 or .25 straight CMOS) were very susceptible to damaging SCR latchup.
A great tool to see if this happens is getting out the thermal camera!
Anyway, SCR latchup is pretty much unfixable. The chip is functionally dead.
-
Does the chip over-drive the LEDs while in reset state or only after coming out of it?
I'm thinking the voltage lock-out chip may have been there because the MCU had power-on reset issues and needed a cleaner reset source than an RC delay.
Since the MCU's reset pin was not drawing 90mA after getting lifted, I wonder where that current was going. Something else must be connected to that reset trace.
-
Since the MCU's reset pin was not drawing 90mA after getting lifted, I wonder where that current was going. Something else must be connected to that reset trace.
Also, that something should be getting pretty warm. Same for the 200mA input current - something should be heating up.
Anyway, it seems that the reset pin needs a delay or a clean signal, the way I would do this would be to use a bigger cap (to slow it down) and a Schmitt trigger.
-
After one early attempt the entire debug was done with dip switch one set to the ON position. Can you tell if this is just digitally sampled to reset ID codes or is it also related to the reset circuit? Are you sure this was not holding the processor in reset and just being fought with the 30 ohm resistor (hence power consumption)?
I would put everything back and check that dip switch is not faulty!
-
Dave measured the RESET line at 12K to ground iirc
-
Are you SURE the original 10K resistor is not to GROUND?
Yes, I'm sure. You can see the traces, and I measured it.
PS, units current has gone up because you have a 270Ohm short to ground!
No, the current goes up all on it's own!
-
Anyway, SCR latchup is pretty much unfixable. The chip is functionally dead.
Yep, that's what I suspect.
-
For some reason this one is the worst one so far for video quality :-(
Oh FFS, are you still on about this?
You are comparing video quality on what youtube is producing using whatever codec it want's this week, on your connection and machine which as has been demonstrated has an issue that is degrading quality.
The problem is not the video quality I am uploading!
-
After one early attempt the entire debug was done with dip switch one set to the ON position. Can you tell if this is just digitally sampled to reset ID codes or is it also related to the reset circuit? Are you sure this was not holding the processor in reset and just being fought with the 30 ohm resistor (hence power consumption)?
Yes, I am sure. If another person comments on this on Youtube I'll scream!
The DIP switch goes to an I/O pin, nothing to with the reset line at all, it's a software function.
And yes, I have tested with the DIp switch off, makes absolutely no difference to anything.
-
Does the chip over-drive the LEDs while in reset state or only after coming out of it?
I'm thinking the voltage lock-out chip may have been there because the MCU had power-on reset issues and needed a cleaner reset source than an RC delay.
Yes, but that's not the real issue, the real issue is the excess current.
If there was no excess current issue then I would have solved the reset problem one way or another.
Since the MCU's reset pin was not drawing 90mA after getting lifted, I wonder where that current was going. Something else must be connected to that reset trace.
It's most likely SCR latchup, the chip has been damaged.
-
After one early attempt the entire debug was done with dip switch one set to the ON position. Can you tell if this is just digitally sampled to reset ID codes or is it also related to the reset circuit? Are you sure this was not holding the processor in reset and just being fought with the 30 ohm resistor (hence power consumption)?
I would put everything back and check that dip switch is not faulty!
It's a DIP switch to erase the configuration, that has nothing to do with the reset line of a processor. Otherwise this would be a design where every powerup has the configuration erased.
-
Ahh - armchair remote debugging - gotta love it!
-
It's most likely SCR latchup, the chip has been damaged.
So, the 5v rail capacitor went out, too much ripple caused a latch-up issue that wrecked the chip? Even though you fixed the capacitor problem, the chip is still dead... ?
POR IC and circuit was probably fine... ?
-
#1:
Couldn't the not properly reset micro result in the excess current draw? - since it doesn't happen all the time.
Maybe if test that reset chip still works, it might. (just whack 5V on it and check the output)
#2:
power up ramp being too slow due to current limit causing a brown out and latch-up behavior.
I know one can cause latch ups by say putting current into an IO pin of a Micro before the supply rail of said micro is up.
Its powered by 24V, so there might be some pin that is connected to 24V through a voltage divider to an IO and the 5V rail now takes too long to get up.
-
Looks like only the two center (yellow?) LEDs go "hi-brite," is that right? (If so, why only those two?) How are the LED driven; what's the current path? I'd expect a current-limit resistor and LED in series, with a uC pin pulling it low to light it, so how could it possibly go "hi-brite?"Anyway... First thought that's popped into my sleepy mind is a "ground fault" somewhere around the uC; probe voltage between supply ground and ground traces/points on the PCB . But I'm also curious about the 5.2V on the 5V rail; have you taken a look at the Vreg circuit; what does it look like it should be; maybe 5.2V is a symptom of something, even if it's still in spec; maybe the uC doesn't like 5.2V. Also, when the LEDs are "hi-brite" what is the 5V rail at?
:=\
-
I'd expect a current-limit resistor and LED in series, with a uC pin pulling it low to light it, so how could it possibly go "hi-brite?"
Maybe a PWM with a higher current to increase the apparent brightness, that sometimes fails and goes 100% on when the CPU crashes.
-
The MCU is a16-bit M16C/62, now owned by Renesas, and they have lots of info on that series. They can be factory programmed (hence the laser engraving) and, at the customer's choice, made so that the firmware is neither readable nor changable. Note: you can still buy them at Digikey, and they're supported by GCC.
-
I found something on latchup here:
http://documentation.renesas.com/doc/products/mpumcu/rej09b0167_m16c62ano.pdf (http://documentation.renesas.com/doc/products/mpumcu/rej09b0167_m16c62ano.pdf)
When different power supplied to the system as shown in figure 1, and input voltage of unused
dedicated input pin is larger than voltage of VCC pin, do not connect dedicated input pin and
power supply directly. Connect to VCC via resistor (approximately 1kohm) as shown in figure
2. This note is also applicable when VINPUT exceeds VCC during power-up.
3. Cause
When dedicated input pin voltage is larger than VCC pin voltage, latch up occurs.
So it will latch up if VINPUT exceeds VCC during power up, which might explain why it's intermittent. Maybe a voltage spike of some kind, perhaps if the regulator kicks a bit too high during start up and there's somehow a lower impedance path to a VINPUT pin so VINPUT exceeds VCC. Maybe singleshot the 5v line and input pins during a non-boot mode and a boot mode
From another document: http://www.cucat.org/general_accessibility/accessibility/colour-sensor/M16c%20Tools/M16Umanual.pdf (http://www.cucat.org/general_accessibility/accessibility/colour-sensor/M16c%20Tools/M16Umanual.pdf)
On P. 179 it mentions that noise can cause a latchup and to put in a .1uF cap between VSS and VCC. It also mentions using a 5K resistor on VPP, though I'm not sure if that matters after it has been programmed as it is an OTP.
Since you said it may work one out of five times, maybe set up a small 555 timer chip circuit that keeps pulsing the reset line until there is some sign of life in the processor. Just crazy idea.
If you do ever get this thing working, you should definitely read the EEPROM and hex edit in a new name in there like "Fixed by Dave Jones"
EDIT: Ok I started watching the EEVBlog scr latchup video and you've basically explained that overdriving an input is a common cause of SCR latchup, so I may not have said anything up there that helped. But still curious of that's somehow happening.
-
I'd expect a current-limit resistor and LED in series, with a uC pin pulling it low to light it, so how could it possibly go "hi-brite?"
Maybe a PWM with a higher current to increase the apparent brightness, that sometimes fails and goes 100% on when the CPU crashes.
Except that most of the time the CPU is in reset mode (until Dave found that it was in reset mode) and the LEDs light up normally. I doubt that the MCU in reset mode was outputting any kind of PWM...
-
Personally, I suspect that Stoneent might be on to something...
The actual SCR latchup may well be caused by the residual charge left on the !RESET capacitor in the RC reset circuit. This can easily be proven by simply connecting a diode (preferably a 0.3V Schottky) from the RC network to the 5V rail so that the reset cap will quickly discharge into the 5V rail and thus eliminate the potential latchup if the system is re-powered too soon.
-
Personally, I suspect that Stoneent might be on to something...
The actual SCR latchup may well be caused by the residual charge left on the !RESET capacitor in the RC reset circuit.
I recall it doing this without a cap at one point.
-
Previously you were uploading at 25 fps and YouTube is fine with that, it doesn't re-encode it for the 1080p stream.
Youtube always re-encodes video!
If you are not interested in improving it that's of course fine, no need to bite my head off.
Sorry, but I've just seen this multiple times from you now, it had gotten rather monotonous.
I proved in the last conversation about this that there is no loss of detail in the 50fps video. So any perceived quality must be at your end in some way shape or form. And someone alluded that there are different ways youtube delivers it depending upon your configuration.
I thought you were genuinely interested in the subject since you made a number of comparison videos and asked for comments on the subject.
I am, but I think it's done and dusted. I've proven there is no loss of detail in the 50fps video as you claimed.
You keep claiming it's horrible, worst ever, or whatever. Why is noone else complaining? I can only presume it's something at your end.
-
I thought it was rather funny when Dave called bullshit in regards to the installation company indicating that the unit has passed it's use by date.
Then he said that it should display their name if working and then I thought shit, hope it doesn't come back to life and shortly after it did.
:bullshit: :-DD :scared:
Muttley
-
The installation company is almost certainly full of shit when they say they can't get a replacement. 5 minutes on Google turned up a dozen places selling that module for about US$200.
-
The installation company is almost certainly full of shit when they say they can't get a replacement. 5 minutes on Google turned up a dozen places selling that module for about US$200.
Agreed.
Muttley
-
Sorry, but for me, something still doesn't add up here!
If it were some issue with the micro, i don't think it would have changed by Dave poking round on the rest of the circuit (of course it could have done, i just think it unlikely)
Looking at pin outs for various SOT23-5 reset controllers, pin 4, the one with the 10K resistor and capacitor RC filter hanging off it, is quite often a manual reset (MR) or WatchDog Input (WDI) and the "RESET" pin is pin 1, over on the other corner of the device.
In this case, the 10K to the 5v rail would be forming an extra timedelay for the reset controller to be coming out of RESET after power up (we can assume it is the MR option not the WDI as that requires the pin to be toggled by the micro to kick the dog)
Possible??
-
Some points make no sense.
Using a RC filter at the output of a reset controller is unusal, but there are reset controllers with open collector outputs: The resistor is the pullup and the capacitor only serves for emi suppression.
But I have never seen a latchup of an input only pin without an increase in supply current. If a pin dies due to overvoltage it typically has a low impedance to gnd or vcc even without supply voltage. But this is not the case here.
The other strange thing is the higher LED brightness in latch-up state: The M16C series has week output drivers. It can not drive LEDs directly (at least not bright enough for use in daylight conditions). My guess would be a simple transistor to drive the LEDs, but then it would be impossible to increase the brightness.
A failed power supply because of a dead cap sounds plausible. It may have caused further faults due to spikes at the output voltage.
But there are a few things that are unusal:
The whole unit is powered by 24V dc. It only draws 70mA. Thats 1.7W. The power regulator has to dissipate max. 1.3W if everything runs at 5V. The area around the 5V regulator seems too small for this power level, therefore it does probably does not provide all the power, otherwise it would run quite hot. The board does not seem getting hot, at least I could not see any discolouration around the regulator. I would have expect a switching power supply, because 24V->5V gives otherwise a bad efficiency and those yellow/green backlights often take 50-200mA to get a decent brightness.
Why did the cap fail? There is basically no ripple on a linear regulated dc supply, therefore the cap is not stressed at all. Or is there a switching regulator hidden somewhere? The inductor looks like a common mode choke, but a switching regulator with failed caps could explain some of the problems.
-
I found the compatibility chart between the GF-GH-GT series.
http://www.aiphone.com/home/assets/GF-GH-GT-Compatibility-Chart.pdf (http://www.aiphone.com/home/assets/GF-GH-GT-Compatibility-Chart.pdf)
The compatibility looks pretty poor between the GF and the GT series.
-
If it latches up, does that mean the 5V rail would drop down to one diode drop (0.7V?)?
And if so, then the micro can't be driving the LED's directly, because then they wouldn't go bright on latchup, or am I missing something?
Also if a chip goes latchup, does that inevitably mean it's dead? Because if it works every 5th time or so, is that dead then?
-
I expect that Dave has already taken this into account but these door stations are not stand alone, they are wired back to a GFBC ( Bus Controller ) and room stations and relays for the gate or door strike are fed off the GFBC.
This unit may get a start/ poll pulse from the GFBC and could simply be offline through other factors, cabling etc, although this does not shed any light on the current draw issue.
Another door station on site would soon tell by swapping them around, we just don't know enough, did the company try this, I wonder.
Just a thought. :-+
Muttley
-
Ohh I forgot! I love watching repair videos, even if they don't have a happy end, Dave.
Nice watching you brachiate through a circuit that isn't working. I think you can learn a lot by figuring out why something is not working.
-
So I am not the most knowledgeable with hardware but can somewhat understand the basics of what he talks about. Is there any reason to assume that the over current is not tied to an unrelated issue? An intermittent failure with a cap or other component causing a short somewhere? I suppose you would need to schematics to see where a short between 5v lines would cause that.
Or would be due to the failure of the reset mechanism in the chip causing the excess current draw.
PS Dave: First post! I've been watching your videos for like 3? years now and I love them. Feel like I learn quite a bit. Still don't understand it enough to read simple circuits and draw a graph like you did in the #708. I did buy a Hako 888D after remembering your recommendation(My $5 120v pen died after 5 years) and its night and day. I never realized solder work could be quick and easy like that. Plz don't stop making videos, Even when your 95 years old on life support in a hospital. Well maybe...
PPS Dave: Video quality is fine but I'm an uneducated brute. Take that as you will.
-
You can almost make a case for just doing away with that calling panel altogether. Since practically everyone (including children) have cell phones, intercom systems like that are nearly extinct. Of course, you still need a way for the tenants to open the door when they get a call (cell or intercom) from a visitor. But that could be as simple as a contact-closure. And tenant entrance could be controlled with an RFID card, etc.
-
You can almost make a case for just doing away with that calling panel altogether. Since practically everyone (including children) have cell phones, intercom systems like that are nearly extinct.
What about delivery guys, etc?
-
Delivery people know who they are delivering to (name and phone number).
If they DON'T know, then they might be a terrorist delivering a bomb and you probably shouldn't let them in.
And regular trades people would probably be issued an RFID card to open the gate for themselves.
-
What about delivery guys, etc?
Well, if they don't have a cellphone, they can still shout. Or throw rocks at the windows... :-DD
Delivery people know who they are delivering to (name and phone number).
If they DON'T know, then they might be a terrorist delivering a bomb and you probably shouldn't let them in.
If you, your spouse and your children each have a cellphone, which one should the delivery guy call? Yours? What if you are not at home, but your spouse is? This is getting awfully complicated quickly...
-
I'll stop trying to be helpful.
Off topic, but did you know your signature is wrong? It is kibibyte which is 1024.
https://en.wikipedia.org/wiki/Kibibyte
-
If you, your spouse and your children each have a cellphone, which one should the delivery guy call? Yours? What if you are not at home, but your wife is? This is getting awfully complicated quickly...
I suspect most of us live in places where the delivery person can just knock on the front door or ring the door-bell.
If nobody answers at a business phone number, then nobody is there to receive the delivery anyway, so what's the issue?
-
The installation company is almost certainly full of shit when they say they can't get a replacement. 5 minutes on Google turned up a dozen places selling that module for about US$200.
Agreed.
Muttley
If they go that route you wouldn't even need it programmed by an installer. The micro is OTP probably for AIPhone. The dip eeprom would have thw install specific data in it and could be copied and flashed or swappes into the new unit.
-
If you, your spouse and your children each have a cellphone, which one should the delivery guy call? Yours? What if you are not at home, but your wife is? This is getting awfully complicated quickly...
I suspect most of us live in places where the delivery person can just knock on the front door or ring the door-bell.
If nobody answers at a business phone number, then nobody is there to receive the delivery anyway, so what's the issue?
This is the reason those system are found on apartment buildings without a doorman. You can't just open the door to a ring, without knowing hwo is ringing the door bell. Even if you are expecting the pizza guy.
-
I suspect most of us live in places where the delivery person can just knock on the front door or ring the door-bell.
Nope.
-
Great video, I was glued to it all the way through.
And you are right Dave it's not so much the final result but the process you follow.
I want to blow some shit up and send it to you for more repair videos :scared:
-
So I am not the most knowledgeable with hardware but can somewhat understand the basics of what he talks about. Is there any reason to assume that the over current is not tied to an unrelated issue? An intermittent failure with a cap or other component causing a short somewhere? I suppose you would need to schematics to see where a short between 5v lines would cause that.
That's actually a really good point. Although it does appear to be a classic latch-up, sometimes you can get things like half-on transistors or floating pins that cause high currents when the micro isn't running properly. Sometimes the firmware engineers don't properly account for the start-up sequence and don't notice the problem because the micro is running a few milliseconds after everything powers up and it comes out of reset.
Yay I said something smart.
-
Is there any reason to assume that the over current is not tied to an unrelated issue? An intermittent failure with a cap or other component causing a short somewhere? I suppose you would need to schematics to see where a short between 5v lines would cause that.
Or would be due to the failure of the reset mechanism in the chip causing the excess current draw.
The overcurrent could very well be unreleated to the reset issue, but it's most likely they were both caused by the fault.
The most likely scenario we have evidence for so far is that something took out some aspect of the reset circuit. Might have been the failed 5V rail cap failing causing over voltage.
SCR latchup is a strong possibility. Once again, might not be, but you won't know unless you spend more time tracing the circuit and troubleshooting. Could be many many hours of dicking around, only to eventually come to the conclusion that it probably is SCR latchup. or you could hit a winner, but you don't know unless you put the hours into it.
It's unlikely you'd get another programmed chip, and you wouldn't risk putting back into a service a device with potential SCR latchup issues.
This one is just way too big of gamble.
And some people have complained that I didn't fix it and I wasn't creative enough etc.
At some point in cases like this it comes down to how bad you want/need to repair it.
Well, for me, this is not my fight, I don't care enough to trace it further, and I have a strong hunch it's SCR latchup. That's good enough for me to call it quits on this one knowing the odds of success from this point on.
I'm very confident I'm not going to crack it with another 30 minutes of work.
It is highly likely this thing is screwed and I will have wasted a lot of time for nothing.
-
Great video Dave, not sure if you saw my YouTube comment but have you tried to contact AIPHONE (not the contractor) to find out if the new models are interchangeable.
Someone on twitter pointed out their product page that very specifically states the GT is not backward compatible with the GF.
-
I did not understand how connecting the current meter acting as 100 ohm resistor to the reset line would pull the line high. Doesn't that reset chip work by pulling the reset line to ground? Anyone catch how that was supposed to work?
-
I did not understand how connecting the current meter acting as 100 ohm resistor to the reset line would pull the line high. Doesn't that reset chip work by pulling the reset line to ground? Anyone catch how that was supposed to work?
i was putting the 100ohm across the 10K pullup.
-
Could it be that the traces that power the MCU are faulty in some way and the MCU is actually getting powered via the RESET pin?
-
Dave you did not waste your time at all you made a very interesting video and I am sure it was enjoyed by many forum members,in a commercial environment the end result would be the same as yours not worth the time.Cheers
-
Great video :-+
Even though there is no rise time specified in the datasheet (page 14), I would try to patch a POR device (the TPS3809 can tolerate 5V).
-
Looks very much like brown out caused by an unstable or slowly ramping up power supply causing the micro to lock up. I remember a product line at my previous employer displaying just this characteristic, the PIC54 or PIC55 would work fine until the battery was discharged and recharged from a certain level, we were using a standard RC and diode reset circuit no amount of messing with these component values would solve the problem!
When you had the issue of "it works one time in 5" I bet if you leave it longer and let the caps discharge fully you get a higher % success rate, quick switching on/off just dips the 5v rail slowly.
We fitted one of the MCP voltage supervisors and all was well again.
http://ww1.microchip.com/downloads/en/AppNotes/00686a.pdf (http://ww1.microchip.com/downloads/en/AppNotes/00686a.pdf)
A faster solution might be to do a little 555 circuit to give the PS all time to settle.
P.S. Keep the repair videos coming, great for those of us into repairs but also a great resource for designers as there is so much to learn from seeing what's gone wrong in other products.
-
I really enjoyed this video as it shows me how a professional debugs a problem. It was quite a learning experience and it's also great to know I'm not alone in making an ass of myself when I think I've solved the problem only to see it's far worse than I thought. :-+
I'd love to see more videos like these.
-
Excellent video :clap: Very educational for my level :-[ The fact that you did not totally fix it is irrelevant to its diagnostic educational value
-
Haven't bothered reading the entire thread for suggestions (and neither have I watched the last 10 minutes of the video yet), but couldn't the symptoms of the Reset-line be caused by a partially dead cap on the line?
Say, if the cap in the RC-network there has failed almost short, it will pull the line low unless you can counter it with a low enough R on top (ie. by putting another resistor in parallel as Dave did) to make it a voltage divider again. Or am I just thinking bullshit now? ;D O0
-
Dave removed the cap on the reset line but it didn't seem to make a difference.
-
Ah, okay, didn't catch that bit.
-
"It is highly likely this thing is screwed and I will have wasted a lot of time for nothing. "
This is not true as the time was not wasted, we all got to see inside something new and the blog members learned some more about fault finding.
-
Could it be that the traces that power the MCU are faulty in some way and the MCU is actually getting powered via the RESET pin?
I have seen this happen with other designs/parts.
-
You probably did this but I don't recall seeing it on the video:
What I recall was that the "reset" trace would not go high even after you lifted the MCU pin.
Was it still 12k to GND? I'd lift the cap to make sure it wasn't bad. Then find whatever was
pulling that trace low.
-
"It is highly likely this thing is screwed and I will have wasted a lot of time for nothing. "
This is not true as the time was not wasted, we all got to see inside something new and the blog members learned some more about fault finding.
When the checks stop coming from google, that's when you've wasted your time.
-
"It is highly likely this thing is screwed and I will have wasted a lot of time for nothing. "
This is not true as the time was not wasted, we all got to see inside something new and the blog members learned some more about fault finding.
Yes, I meant if I continue with it from this point.
-
Great video Dave, not sure if you saw my YouTube comment but have you tried to contact AIPHONE (not the contractor) to find out if the new models are interchangeable.
Someone on twitter pointed out their product page that very specifically states the GT is not backward compatible with the GF.
No worries, I don't have a twit ter account :) >:D
-
seen this before. Used some form of averaging mode and not seen the wobbly rail. The chip as a arsey reset and the wobbly line is the problem. It's unlikely that the latch up as caused any issues and the chip just needs its reset invoking correctly. Unless you let the latch up catch for long it won't do any harm that's what's the sot packaged is there to prevent. You had the current limit set conservatively for most the tests.
-
I dunno. One of the things you pick up when you fix things regularly is when something should be marked as NFR - Not For Resuscitation. There are the clear faults where a component or physical thing has failed; not always quick to find, but unambiguous when you do and unambiguously fixed thereafter. There are the clear beyond economic repair units, where the damage is too widespread, faults have cascaded, or parts are unobtainable/too expensive. And then there are the heartsinks, which sort of limp on after you've sort of fixed the problem, but you're not quite sure that you have and the behaviour isn't solid enough to let you be confident that you fully understand what's going on. When you factor in your time and effort - and in particular, what else you could be doing instead - that final category of repairs gets old really quickly,
Nobody likes walking away from something where there's a chance that one more push will ensure victory and if you're a hobbyist who enjoys the chase then these things can be kept going for a long time (I spent more than a year on a mammothly complicated colour dual-standard buggered TV chassis when I was a kid; it was great fun and I learned a lot. It never worked.) Later in life, not so much.
I guess everyone who follows EEVBlog does so because they have a passion for electronics, whether or not it's their job as well. Sorting out hard problems can be addictive (I remmeber a really good column called In Your Workshop in one of the UK TV technical magazines, which specialised in that.)
Sometimes, though, you have to look at a quivering patient on the table, flip the switch and throw the sheet over its head. There's always another.
-
Forget the SCR/power circuit, does it work properly if powered directly off a 5V supply ?
I'm sure you could get a proper 24 to 5V module that would fix inside that casing.
I'd also try putting that SOT reset chip back into the circuit, using flying leads. See if that part is fine, and the power/RC components were the issue.