Category Archives: Teardowns

LG 32LC56 Power Supply Repair

I recently inherited a completely dead LG 32″ LCD TV from my parents. Apparently this TV set was working fine one day and completely dead the next. So I thought I would have a look and see if I could get it back up and running. Upon receiving the set the first thing I did was try and power it up. Nothing completely dead. No standby light nothing. Checked the fuse in the plug (obviously) and that was fine. Time to dig a bit deeper.

With the current symptoms the obvious suspect is going to be the power supply. The internet is strewn with examples of power supplies going bad in these TVs and people on eBay are even selling repair kits for anyone wanting to repair them.

After carefully removing the back panel I had managed to expose the power supply board. I must say a bit of a beast by all accounts. But if you think about the job it has this is to be expected. Fortunately most of the connectors were labelled with the expected output voltages. Probing around on these pins showed no voltage on any of them. Checking the mains into the board gave a reading of around 230V AC. Checking the voltage after the 5A fuse on mains input read nothing. Turns out this fuse had blown. Question is why?

On closer inspection smoke damage can be seen on the large heat sink holding the power transistor, bridge rectifier and rectifier diode on the input stage. My first thoughts were one of these may have been damaged but on closer inspection it turns out the smoke was caused by a 220 pF 2Kv ceramic disc capacitor just in front of the heat sink (shown in the image above directly between the transformer and the heat sink) exploding. Which explains why the fuse may have blown. Probing around the remainder of the input stage the other components appeared to be fine as far as I could tell. Turning my attention to the electrolytic capacitors (shown above) on the output stage I could immediately see a number of these were starting to show the tell tale signs of failure with at least three of them having significant bulging. So I decided I would replace all of them just as a matter of course along with the ceramic disc capacitor that had blown.

Once all of the new components had arrived and been fitted along with a new fuse I powered up the board on the bench and now had a 5V standby voltage present. After fitting the board back into the TV and a quick press the power button on the side and the TV sprung back into action. Result. So a nice easy fix this one. Total spend was about £3 whereas a refurbished power supply board runs to around £30. And for a TV only worth probably that in the first place it hardly seems worth it.

Advertisements

TP-Link WDR4300 Router Recovery

My new wireless router decided to stop working at the weekend. It has been behaving rather strange for the past few days. I’ve tried power cycling in the vain hope a reboot may fix the issue. Which it didn’t. And to make things worse now it wont even boot. Pinging it gets no response either. The original firmware was replaced with DD WRT, a great Linux alternative firmware, so the first thing I did was head over to the DD WRT homepage for help. I tried the recommended 30/30/30 reset procedure which didn’t solve the issue.

Luckily there is a ton of resources out there surrounding these routers. Once such resource I found extremely useful was the OpenWRT Wiki page. Apparently the WDR4300 has an Atheros AR9344 SOC running at 560 MHz with 8MB of flash and 128 MB DRAM. It also has both a JTAG and serial programming/debug connection. The flash memory is made up of the boot loader (U-Boot), the operating firmware and the ART (which contains MAC addresses and calibration data for the wifi). It’s also the boot loaders responsibility for configuring the serial interface.

WDR4300_1With nothing to lose I begun disassembling the router to see if I could get access to this serial port and maybe diagnose the problem. After removing the aerials and the screws holding the case together I had the router disassembled. There are two unpopulated headers one 14 pin, which I assume must be the JTAG connection, and one 4 pin which turns out to be the serial connection. The four pins comprising the two supply lines and the TX and RX lines. I soldered in a pin header to the board and connected my USB to serial converter. The connection settings according to the OpenWRT Wiki page are 115200 8N1 with no flow control. Using puTTY I managed to capture the routers output during power up.

 U-Boot 1.1.4 (Apr 25 2012 - 18:29:12)  
 U-boot DB120  
 DRAM: 128 MB  
 id read 0x100000ff  
 flash size 8MB, sector count = 128  
 Flash: 8 MB  
 Using default environment  
 In: serial  
 Out: serial  
 Err: serial  
 Net: ag934x_enet_initialize...  
 No valid address in Flash. Using fixed address  
 wasp reset mask:c03300  
 WASP ----> S17 PHY *  
 : cfg1 0x7 cfg2 0x7114  
 eth0: ba:be:fa:ce:08:41  
 athrs17_reg_init: complete  
 eth0 up  
 eth0  
 Autobooting in 1 seconds  
 ## Booting image at 9f020000 ...  
 Uncompressing Kernel Image ... OK  
 Starting kernel ...  

The output shows the boot loader initialising the serial port. After initialisation the boot loader attempts to auto boot the image at address 0x9F020000. Firstly by uncompressing the kernel image and then starting it. Additional serial output follows before we encounter a raft of file system page read errors before stopping.

 start service  
 starting Architecture code for wasp  
 [ 1.960000] SQUASHFS error: lzma returned unexpected result 0x1  
 [ 1.960000] SQUASHFS error: Unable to read page, block c523, size dd54  
 [ 2.030000] SQUASHFS error: lzma returned unexpected result 0x1  
 [ 2.030000] SQUASHFS error: Unable to read page, block c523, size dd54  
 [ 2.100000] SQUASHFS error: lzma returned unexpected result 0x1  
 [ 2.100000] SQUASHFS error: Unable to read page, block c523, size dd54  
 [ 2.170000] SQUASHFS error: lzma returned unexpected result 0x1  
 [ 2.170000] SQUASHFS error: Unable to read page, block c523, size dd54  
 [ 2.240000] SQUASHFS error: lzma returned unexpected result 0x1  
 [ 2.240000] SQUASHFS error: Unable to read page, block c523, size dd54  
 [ 2.310000] SQUASHFS error: lzma returned unexpected result 0x1  
 [ 2.310000] SQUASHFS error: Unable to read page, block c523, size dd54  
 [ 2.380000] SQUASHFS error: lzma returned unexpected result 0x1  
 [ 2.380000] SQUASHFS error: Unable to read page, block c523, size dd54  
 [ 2.450000] SQUASHFS error: lzma returned unexpected result 0x1  

So it appears the firmware may have become corrupted. The obvious next step then was to try re-flashing it. After some reading around on the subject (being a complete Linux novice) I discovered the boot loader supports network transfer via the Trivial File Transfer Protocol (TFTP). So it is possible to transfer the firmware image via TFTP and re-flash it.

The first step was to download the required firmware images and other supporting software. I downloaded the DD-WRT firmware image files from here and then downloaded and installed the client side TFTP server program TFTPD32 from here.

The next step was to break execution of the boot loader in order to run tftpboot. To do this, within putty after power cycling, simply wait for the message “Autobooting in 1 second” to appear begin typing “tpl” and pressing enter until the sequence stops and the prompt “db12x>” appears. Once the prompt appeared I ran “tftpboot”. I then made a note of the expected server address “192.168.1.100” and load address “0x81000000”. I then exited tftpboot by pressing Ctrl+C.

 db12x> tftpboot  
 dup 1 speed 1000  
  Warning: no boot file name; using '6F01A8C0.img'  
 Using eth0 device  
 TFTP from server 192.168.1.100; our IP address is 192.168.1.111  
 Filename '6F01A8C0.img'.  
 Load address: 0x81000000  
 Log: *  
 TFTP error: 'Access violation' (2)  
 Starting again  

With the router connected directly via an ethernet cable and all wireless adaptors disabled I set the network adaptor to the static IP address “192.168.1.100”. I then ran TFTPD32, browsed for the folder containing the firmware images and set the server address to “192.168.1.100”.
I then ran “tftpboot” again with required load address and source firmware parameters. The new firmware then begun transferring. Upon completion the message “done” appeared and the number of bytes transferred was shown.

 db12x> tftpboot 0x81000000 factory-to-ddwrt.bin  
 Using eth0 device  
 TFTP from server 192.168.1.100; our IP address is 192.168.1.111  
 Filename 'factory-to-ddwrt.bin'.  
 Load address: 0x81000000  
 Lg: #################################################################  
      #################################################################  
      #################################################################  
      #################################################################  
      #################################################################  
      #################################################################  
      #################################################################  
      #################################################################  
      #################################################################  
      #################################################################  
      #################################################################  
      #################################################################  
      #################################################################  
      #################################################################  
      #################################################################  
      #################################################################  
      #################################################################  
      #################################################################  
      #################################################################  
      #################################################################  
      #################################################################  
      #################################################################  
      #################################################################  
      #################################################################  
      ############################  
 done  
 Bytes transferred = 8126464 (7c0000 hex)  

Before the new firmware image could now be copied the destination flash the destination flash first needed to be erased. The destination address being 0x9F020000 (which we know from the initial captured output) and destination length being the size of the transferred firmware image 0x7C0000 bytes.

 db12x> erase 0x9f020000 +7c0000  
 First 0x2 last 0x7d sector size 0x10000                                                                                                 125  
 Erased 124 sectors  

Once erased the new firmware could then be copied over from the destination flash. Again the destination address being 0x9F020000, the source address being 0x81000000 and the length 0x7C0000 bytes.

 db12x> cp.b 0x81000000 0x9f020000 0x7c0000  
 Copy to Flash... write addr: 9f020000  
 done  

So that all appeared fine all that all that remained was to reboot and hopefully everything would be working.

 db12x> reset  

Much to my relief that appeared to have fixed the issue. The router now booted fine and I was able to access to the DD-WRT web interface. WDR4300_7I then went ahead and performed a web flash using the web flash firmware image file previously downloaded. I am not entirely sure this stage was necessary but some of the guides I had read previously did and I cant imagine it would do any harm doing so.

So overall a great result. Saved myself some money not having to rush out and buy a new router and learnt a little bit about Linux in the process.

 

8 Channel Logic Analyser

Having recently had some issues trying to debug SPI communications on a development board I built I decided it was time I looked into purchasing a logic analyser. Now I know these things can retail for mega bucks but I also know you can get more reasonably priced USB based versions as well. Now I am not going to get some 100 Mhz 18 channel beast for peanuts but I was optimistic I could find something suitable.

Saleae-logicCue the Salae Logic. This little beauty can sample 8 channels at up to 24 Mhz and record upto 10 billion samples. With 17 different protocol anaysers including I2C, SPI, CAN and many more this appears to be ideal. It comes with its own case and wiring harness including test clips. All this for €152 (£120) shipped directly from Saleae.

 

Dave Jones recently did a review of the Salae Logic on this on EEVblog. Watching his video it becomes clear there really isn’t a lot of hardware in this device. Its based on the Cypress CY7C68013A microcontroller. This is a 8051 microcontroller with a built in USB transceiver. The input logic signals are sampled on 8 GPIO lines and transferred over USB back to the host software.

There are a number of Salae Logic clones available on the internet for a fraction of the cost. This only being possible due to the fact that Salae supply their software for free. Now that left me with a moral dilemma. Do I shell out £120 for the official version or do I buy a clone for around a tenth of the price. I knew deep down this is most likely only going to get an outing once in a blue moon so the idea of spending £120 for something that is going to sit in my draw the majority of the time was difficult to justify. On the other hand I appreciate all the hard work that has gone into the development of this kit and this is at the end of the day a source of income for these guys.

So after a bit of pondering I made a decision, I will purchase one of the clones, see how well it works, see how I get on with it and then if I end up using more than twice a year I’ll buy the official version. In the end I managed to buy one complete with wiring harness and clips for £15 delivered. A bargain in anyone’s book but only time will tell what the quality is like.

Salae Logic ClonesUpon receiving it I followed Dave Jones philosophy of “Don’t plug it in take it apart”. The quality of the soldering was adequate. There didn’t appear to be any shorts and all the components were fitted correctly. No surprise this uses the same CY7C68013A as the official version. One interesting thing about this micro controller it executes code from internal RAM downloaded over USB, loaded from EEPROM or from an external memory device. On closer inspection this board has an Atmel 24C02 2Kb (256 byte) serial EEPROM fitted. Interesting. Is it possible the firmware could be stored in this EEPROM and loaded into RAM for execution on power up? Though 256 bytes doesn’t seem a lot even for a modest bit of firmware. This leads me to think the firmware is more than likely download by the host software when first started. So its possible this EEPROM maybe used to store the Vendor ID (VID) and Product ID (PID) which must be the same as the official Salae device. Closer inspection also reveals that each logic input passes through a HC245 3 state octal bus transceiver before connecting to the micro controller. This provides some level of protection for the GPIO lines. Stock series resistors are present on each input as well as pull up/down resistors. No diode clamping though like the official version. Note there is also 3.3V regulator fitted on the reverse side of the board.

Having already downloaded the latest version of the Salae Logic software (1.1.15) I plugged in the device for the first time. It identified itself as correctly as a “Saleae USB Logic Analyzer”. First impressions of the Saleae Logic software is its very good indeed. I love the dark theme which really makes everything stand out. Using it is a breeze as well. Simply connect the probes to signals you wish to monitor, choose the number of samples you want and at what frequency you want to sample. The maximum sampling frequency is 24 MHz which is more than fast enough for most applications. Initially I did have an issue when connecting through a USB hub. The software was unable to sample quick enough. Swapping over to a dedicated USB port resolved that issue. After selecting the number of samples and frequency you can simply press the “Start” button to begin sampling. I did notice some cross talk between unused channels which may be problematic but for now I simply hid those channels from view.

One of the main reasons I bought this analyser was to diagnose serial communications problems and so to see just how well it performed I connected it to the MCP3008 10 bit ADC on my variable electronic load board. The sample rate was set to 24 MHz (bit over kill since the SPI is only running at 1 MHz) and 25M samples which equates to around 1 second of data. I selected an SPI analyser in the logic tool and assigned its signals MOSI, MISO, Clock and Enable (CS). The start trigger was set to trigger on a high to low transitions on the Enable signal. The captured data can be seen below.

Saleae Logic

Communication between the micro controller and the MCP3008 requires 3 bytes to be sent. The first byte transmitted contains seven leading zeros followed by a start bit. The second byte transmitted starts with the mode bit (1 = single ended 0 = differential) followed by three bits determining the channel to be sampled (000 = CH0 … 111 = CH7). The remaining four bits are don’t cares. Once the second byte has been sent the micro controllers receive buffer contains five unknown bits, a null bit and the two highest order bits of the conversion result. The third byte sent is a dummy byte. Once the third byte has been sent the micro controllers receive buffer contains the lowest order eight bits of the conversion result. In the example shown the ADC is sampled twice. Channel 0 is sampled first followed by channel 1. Both channel 0 and channel 1 have no sources connected to them and remain floating so both channels read zero counts.

Overall impressions of the this low cost logic analyser a very good. Putting aside the issue with potential cross talk for the price this logic analyser performs very well. It may not be as aesthetically pleasing or as well built as the official Saleae device but for the money you cant go far wrong.

OBD2 Adaptor Teardown

A number of years back a bought one of those cheap bluetooth OBD diagnostic tools from eBay. I cant remember why I bought it now (obviously for use on the car) but I must have only used it a couple of times. Having found in my desk drawer at work last week I decided to take it apart and have a look inside. From what I recall I only paid around £10 for it so was quite intrigued to see what you get for your money.

The device has “ELM327” written on the top of it. For those who don’t know the ELM327 is a programmed micro controller produced by ELM Electronics for translating messages from a vehicles on-board diagnostics (OBD) interface. According to Wikipedia the ELM327 is implemented on a PIC18F2480 micro controller from Microchip. Vehicles that support OBD communicate over one of a number of protocols. For older vehicles this tends to be either ISO 9141-2, ISO 14230-4 KWP or J1850 pulse width and variable pulse width modulation. Modern cars tend to use the controller area network (CAN) protocol. The ELM327 supports all of these protocols.

Further research reveals that ELM failed to implement any code protection on the original ELM327 chips. These chips were then cloned and form the basis for the majority of the cheap Chinese imports you now find on eBay. The version number in the firmware of these clones also appears to have been modified to report versions newer than the original release even though the functionality remains the same. Most of the adaptors currently on eBay claim to be v1.5. I have been unable to find any reference to a v1.5 on the ELM website.

OBD2 Device

Here is a picture of the PCB after it was removed from the case. The OBD connector which is connected via a 16 pin ribbon cable to the pin header has also been removed. The soldering looks good. All the components appear to be fitted correctly. We can see the main micro controller is indeed a PIC18F2480 the same processor ELM use for their ELM327. No labelling here so its more than likely the PIC18F2480 has been flashed with the ripped off firmware.

Now comparing this PCB with suggested example circuit diagram on the ELM327 datasheet. It quickly becomes clear this example has been adopted with some minor modifications. An off the shelf Bluetooth module (middle right) has been added. The RS232 level shifting has been removed since the TX & RX lines on the PIC connect straight through to pins on the Bluetooth module. I haven’t gone over the board component by component but you can clearly see in addition to the main micro controller, the MCP2551 CAN transceiver, the 78M05 5V regulator (bottom right) used in place of a 78L05 on the schematic. The 1.5A 50V rectifier diode in line with the battery voltage for reverse polarity protection. The LM317 adjustable regulator used to control the J1850 bus voltage. There appears to be additional filtering on the board as well.

ELM327 Datasheet

The bluetooth module looks like the e-Gizmo EGBT-046S. Versions on eBay appear to be known as the HC-05 or HC-06. The difference being the HC-05 can be configured as a master whereas the HC-06 cannot apparently. The main chip on these boards is a CSR BC417143 BlueCore® 4-External single-chip radio and baseband IC. Below it is the 8Mbit of external flash containing the firmware.

After applying power to the header and successfully pairing it with my PC I was able to communicate with it using puTTY. The ELM327 AT commands list contains a list of all of the commands supported by the device. Now obviously I couldn’t issue commands to poll vehicle information but I can send AT commands to perform simple tasks such as reset the device or report the firmware version number.

I reset the device by sending an “ATZ” command to which the device responded with “ELM327 v1.4”. Interesting. Sending the command “AT@1” returned “OBD2 to RS232 Interpreter”. This seems to be valid. However sending the command “AT@2”, which is only supported in firmware versions v1.2 and greater, should display the device identifier. The device returned no response. This indicates to me as expected that this device must be one of the cloned originals.

Still putting this into perspective. The original ELM327 chips from ELM Electronics are priced at $18 and that’s just for the IC. Add in the additional cost of the CAN transceiver, the extra components, the PCB and a case and you could not even build one yourself for less than what I paid for it. And besides it works!