I thought I might start posting repairs that I do for my small business called The Resistance.
My Brother HL-L2360DW laser printer went into a reboot loop after a power outage. The LCD initializes and displays solid blocks, followed by a blank screen, and the Wifi button LED blinks once, and then the cycle repeats. Holding the “GO” button either during startup or while it’s looping puts the printer into “Users Mode” which displayed on the LCD. The service manual for this particular model does not mention this mode, but I found another service manual that did. I tried every possible option, but always ended up in the same place.
I removed the access panels on the printer and quickly checked voltages from the low-voltage power supply. I didn’t suspect a problem here, and I didn’t find one… all the voltages measured OK, but that’s always the first step. I then turned to the main PCB (p/n B512386-4) as the issue was almost definitely there. I tried disconnecting all external connections: the HV power supply, laser unit, motor, etc but this had no effect on the issue.
The service manual has a simplified block diagram showing the main PCB components and their connections. There is a Renasas ARM MPU in a 144-pin QFP package that serves as the main controller. This is powered by a 3.3V rail that is generated by a DC-DC converter. This voltage checked OK, as expected. The MPU uses I2C to communicate with an EEPROM as well as an IC which is labeled “HYPNOS” in the diagram. Among other things, the HYPNOS appears to be responsible for sending the AC zero crossing signal to the MPU which is probably for controlling a triac or SCR. I checked the SCL and SDA lines on my scope, and confirmed that the MPU is sending clock as well as data. Entering into “Users Mode” immediately ceases I2C communication, and it doesn’t begin again until the machine cycles.
The MPU also uses SPI to communicate with a serial flash IC (a cFeon QH64) labeled U7 on the board, which is likely used for the firmware. I was able to see SPI clock and data on the scope, so it seemed like the main MPU was intact.
I don’t think the EEPROM (a ST M24C32-W) stores anything absolutely necessary for startup and some of the parameters can actually be set in a maintenance mode according to the service manual. There are also a number of error codes related to EEPROM, DRAM, and flash ROM failure. I haven’t received any error codes, though. At this point I was thinking that the firmware was most likely corrupted given the behavior of the system.
I knew I would need a replacement board due to the current state of repair parts and software availability. I was unable to find an exact replacement board, but I was able to find a board for a Dell E310DW which is essentially a re-badged HL-L2360DW. The part number for the board differs by one digit (B512386-5), and it visually looks identical.
Since a replacement was on the way, I decided to go a bit further to see if I could figure out exactly what was at fault. I desoldered the EEPROM (U1) and there was no change in the behavior. I desoldered the QH64 flash IC (U7), and bam– no output on the LCD. Does this mean that the firmware is actually intact and that the issue is with the EEPROM? I soldered the QH64 back in, and was back to where I started. Observing the I2C and SPI lines, it is clear that the system is simply looping. It attempts to boot, something fails, it restarts, repeat.
Interestingly, the previously mentioned HYPNOS has an output pin labeled “CPURST” as in “CPU reset.” There were several ICs on the board that I was unable to find any datasheets for, so at first I wasn’t sure exactly which one was the HYPNOS. The block diagram showed 7 pinouts, one of which was tied to the AC signal for the zero crossing detection. I was able to trace the pin header for the AC signal from the power supply, and eventually found a 20-pin SMD that looked like it might be the one. I probed around with the scope, and found I2C communication on one of the pins, so I’m fairly confident it was the right one. The IC itself is labeled “510A” with “DN5” on the second line, but otherwise no other identification. I desoldered it, and the system would not boot, so nothing gained there.
I received and installed the replacement board, and the printer is back up and running, albeit as a Dell now:
This at least confirmed what I already knew. The printer was intact other than something on the main PCB. On closer inspection, the Dell board is not quite identical to the Brother, as the flash IC is different. It is a GigaDevice 25Q64CSIG and there is a 10k pull-up resistor on the CS pin which is absent on the original board. The EEPROM is different as well. This new board uses a slower SPI clock at 25MHz, compared to 50MHz for the QH64. I’m thinking that the Dell board might be a slightly newer revision given the part number. I wonder if Brother had issues with the older design given they left CS floating.
I de-soldered the flash IC and whacked it onto a breakout board. I hooked it up to a Bus Pirate:
I used spiflash to extract a .bin of the firmware. binwalk showed that the firmware consists of ARMEB instructions, which is ARM’s “old” application binary interface (ABI) that uses big-endian:
strings output showed an entry for “Users Mode” so it appears that this is indeed part of the firmware. Hmm… does this mean the firmware was actually intact all along? For grins and giggles, I also found entries for “Dell Printer E310dw.” I suppose I could change the name of the printer back to the original Brother model if I wanted… or something entirely custom!
I went ahead and wrote the .bin from the Q64 from the Dell board to the QH64 from the Brother board.
That completed successfully, so I re-soldered the QH64 back onto the original Brother board. I reinstalled the board and turned it on.
Success! Sort of…
The printer booted into maintenance mode. I checked the service manual for the different commands, and printed a test page using command “09”. It worked! With that success, I chose command “01” which automatically set the EEPROM parameters. I then printed a “maintenance information” report using command “77” which confirmed that this Dell firmware is indeed at least newer than the version shown in the service manual:
The “SW CheckSum” shows “NG” which I assume means “not good,” but I’m not sure what this really indicates or what it is calculating a checksum for. After exiting maintenance mode, everything seemed okay. Unfortunately, I then noticed there was no network option in the main menu, and the Wifi button did not respond.
The board uses a Realtek PHY, and after checking the IO line to the MCU, it was clear that something was going awry and the MCU was choosing to shut down the PHY. I went back into maintenance mode and selected option “80” which displays machine log information including the MAC address. No MAC address was listed, so that was almost definitely the issue.
The service manual indicated that the MAC address is stored on the EEPROM, but it is not an initialized parameter. In other words, it is pre-defined on the EEPROM and there’s no way to update or change it from the printer itself:
So, I de-soldered the EEPROM again in hopes of seeing if I could either manually edit the MAC address, or perhaps dump the contents of the Dell board EEPROM onto this one. During this process, the original EEPROM died. It developed an internal short which killed the chip when I was trying to read it. I probably exposed it to too much handling and heat.
I slapped the Dell board back in and the printer (and networking) works fine of course. At some point I may order another EEPROM IC and try the above read & write sequence. For now though, I’m done with this project and mostly accomplished what I set out to do: repair the printer, and determine what went wrong with the original. I think both the firmware and EEPROM were corrupted during the power loss / surge event.
The Compaq Portable was one of the world’s first 100% IBM PC compatible computers, and definitely one of the first real “portable” computers. It’s not really portable by today’s standards as it is nearly 30lbs, but in 1983, it was groundbreaking. A co-worker posted one for sale on a company bulletin board as non-working. He bought it new when it was first released, and hadn’t powered it on until just recently. When he did, there was apparently a loud noise and smoke followed.
Working on old irreplaceable equipment is always a little daunting. Parts availability can be questionable or non-existent, and it’s easy to get in over your head on how far a restoration should go. In this case, I decided that I would restore the system back to working order, but would not go as far as a complete cosmetic restoration. I love vintage hardware, but there are others much, much more dedicated and knowledgeable to preserving these historical artifacts than I am.
I disassembled the entirety of the unit including the CRT. The issue that the previous owner ran into was easy to spot: a tantalum capacitor had shorted and exploded on the power supply board.
After cleaning the surrounding area, it appeared that no other components were damaged, at least from what I could tell visually. Given tantalum capacitors’ propensity to fail in this manner, and the age of the system, I decided it would be justifiable to replace all of them.
Additionally, the keyboard used capacitive foam & foil discs that had long since disintegrated. Luckily, many other vintage systems used similar keyboards (made by Keytronic) so replacements are available.
Replacing the tantalum capacitors was straightforward. Before replacing the keyboard foil discs, I slowly powered the system on using a variac and dim bulb tester. After ensuring voltages were at the expected values, I slowly increased the variac to maximum voltage. The system booted!
Since the system was now working, I went to work on replacing the keyboard discs. This wasn’t a fun or interesting job, but about an hour later, I had a working, usable system on hand.
The 5.25″ drives seem to have a little trouble reading the included MS-DOS (version 1.11!) diskettes. I did not attempt any further repair, as I had mostly accomplished what I set out to do, and I did not want to risk damaging these diskettes.
The Pioneer SX-300 was originally released in 1973 and stayed in production until 1976. It was a small, simple receiver that output 7W per channel. I found one unexpectedly at a nearby estate sale. It was sitting in a basement covered with dust, and the back panel was falling off.
Since the condition was unknown, and who knows how long it had been since it was powered up, a variac was used combined with a dim bulb tester to bring it back to life. This was done slowly to help reform any old electrolytic capacitors, and to ensure there were no potentially damaging short circuits. Luckily, it powered up successfully.
Any receiver this old will have several areas that need addressing. The volume pot, tone controls, and switches all needed cleaning with contact cleaner. The right channel was noisy as well.
The amplifier section primarily uses 2SC1344s and 2SC1345s, both of which are long out of production. Over time, they are susceptible to becoming noisy and failing. These in particular suffered from “black leg” syndrome, most likely oxidation, but it’s unclear whether this is indicative of an issue.
I used cold spray to see if I could isolate the noisy transistor(s) while the radio was playing. I was able to identify the culprit: a 2SC1344.
Since these radios are worth a decent amount of money, and just from the historical value of them alone, I decided to re-vamp the entire radio to ensure it will play trouble-free for years. That meant replacing all the transistors and electrolytic capacitors, as well as a thorough cleaning of all the pots.
I substituted 2N5088 and 2N5210 transistors in place of the 2SC1344 and 2SC1345 respectively. These were compatible with the circuit topology and required no other changes. The footprint of these transistors was different, so I had to carefully bend them into the correct orientation before soldering.
All the electrolytic capacitors were replaced, mostly with Nichicon KL series. These are low leakage capacitors that are excellent for audio applications.
The tuner section worked beautifully and required no alignment.
RCA’s Dimensia line, aside from being pronounced like the neurodegenerative condition, was their top-of-the-line component system produced in the 80s. I purchased the MPA-120 amplifier that was part of this line from a Craigslist post. It was said to power on, but would eventually go into and would stay in protect mode.
It’s a cool chassis design with a separate VU meter for each channel on the front panel display. The amplifier topology utilizes STK modules as is relatively typical for many amplifiers from this era. It is rated at 120 W per channel into 8 Ω.
A visual inspection revealed a charred resistor that actually measured correctly with a DMM. Since the amplifier was portrayed as at least partially working, I powered it on and verified the behavior. The protection mode would kick in after being powered for a few minutes.
After checking the components surrounding the STK modules, and verifying no other visible damage, I began to suspect heat may be an issue. As mentioned above, the protection mode would engage after a few minutes. If the unit was powered off and on immediately, it would almost instantly go back into protection mode.
I used a heat gun to apply heat to various parts of the main amplifier board to see if I could get the protection mode to engage faster, rather than simply waiting for the entire unit to heat up. Eventually I found that heating the protection components themselves would trigger the protection mode.
The Unisonic UPC1237 was used as the IC for controlling the protection mode. On pin 7, a capacitor is used to control the muting period when Vcc is applied. In the MPA-120, a 100uF electrolytic is used.
Since no other issues could be found, either the protection IC or the timing capacitor could have been at fault. I removed the timing capacitor and checked the ESR, which returned with a normal value. I replaced the capacitor regardless to eliminate it as a possibility, and this turned out to be the culprit. The amplifier no longer went into protection mode even after being on for several hours. The capacitor must have had a high leakage current causing the IC to go back into protection mode.