Electronics
M17x inverter brightness fix
After I killed my original motherboard modifying stuff in my 6970m quest, the brightness of my LCD was stuck at low with both the new R1 and R2 motherboards. The function keys couldn’t adjust brightness and neither could windows. Here’s how I fixed it. This is probably only valid for a CCFL backlit display.
The inverter that drives the fluorescent lamps in my display is based on a MAX8759. This chip has an SMBus interface as well as an ambient light sensor interface and a PWM input. The motherboard uses the SMBus interface to control the inverter. You can directly write values to a brightness register, from 0x00 to 0xFF for minimum to maximum brightness. The function keys send incrementally smaller or larger values to the controller. I pulled out my logic analyzer, mbed, and realterm to watch the bus communication and communicate with the inverter controller.
The communication from the EC to the inverter controller is correct, and you can read the brightness register and see the values change based on the function keys. However the brightness continues to stay low. You can also read the fault register, but no faults were present in my case.
What I figured out was the controller by default uses a mode called “SMBus with DPST”, which takes the SMBus brightness value and multiplies it by the PWM duty cycle. This apparently allows another interface to use the PWM input and dim the display without needing to access the bus. The problem was the PWM duty cycle from the EC was 0%, so the controller kept the brightness at 0 regardless of the SMBus setting. › Continue reading
6970m power issues
I was recently working on getting an AMD 6970m working in an R1 M17x. I didn’t get it working, but that’s probably largely due to the fact that I was testing with a bad card.
When the computer powers on, before it POSTs, it applies voltage to the three power rails for the graphics card. The graphics card is supposed to turn on its regulators and when things stabilize assert the MXM power_good signal. This happens before any signals are applied to the card’s busses. However if one of the regulators is out of spec, the power_good signal remains low and the computer will not even start POST so you won’t get any error codes, just a black screen.
I looked up the datasheets for the card’s two main regulators and measured the voltages produced. The regulator that I think probably runs the memory chips (APL5913) was spot-on but the regulator for the core (ISL6228) was off by about a tenth of a volt. Hence the failure to release power_good and continue boot. › Continue reading
Upgrade M17x R1 to R2 motherboard
I have an Alienware M17x that has the Core 2 Quad processor. This isn’t a bad setup, but an i7 in the R2 is much better. There is also the restriction that the R1 can only run the GTX 260m, 280m or AMD 5870m. This makes the M17x mostly obsolete for any modern games. I tried quite a few things to get an AMD 6970m running in the R1 (see here), including modifying the MXM structure in the BIOS. I wasn’t successful, mostly because I eventually figured out that the card I got off eBay to test with was bad. However, I did figure out that an R2 motherboard can replace the R1 motherboard. You will of course need a new processor and the CPU/southbridge is in a different location so you also need an R2 heatsink. Everything else is compatible, and the R2 will run the 6970m.
The only things I had to modify was the LVDS link width for the R1 LCD and the magnesium plate that covers the motherboard. Since the heatsink is in a different location you need to relieve a couple spots.
For the LVDS connection the BIOS for the R2 specifies a 24-bit width and the R1 is an 18-bit width. I modified the MXM system info in the BIOS to fix that and updated the checksum. Then I flashed it to the motherboard. I did this before I figured out the 6970m was dead, so I don’t know if the R1 LCD will work or not without running a modified BIOS since it never POSTed and I fixed the card after flashing the BIOS. › Continue reading
6970m vBIOS ISP / Pm25LD010
My latest project is trying to get an AMD 6970m graphics card working in my first release Alienware M17x. I needed a way to program the flash memory on the card that holds the BIOS, since the system won’t post with the card installed. The flash is a Pm25LD010 which is a 1Mb SPI 3.3V flash chip. I had the programmer I built for the last project with the M17x motherboard BIOS issue, but the SST25VF016B it was programmed for has a different program/erase operation. It’s also a bigger flash.
I modified the code for programming the SST25VF016B so that it works with the Pm25LD010 in the same programmer. If you build the programmer from my previous post this code will program the flash on the 6970m.
The code is C for linux. Just make from the directory, or the zip file here also has a compiled executable.
Alienware M17x BIOS / EC corrupted flash fix
I recently bricked my M17x trying to update the EC firmware for the PS2 scan rate fix. I created a USB Crisis rescue disk from the Dell package and booted from it. The Phoenix Phlash utility then informed me that it couldn’t flash when memory managers were present, and that I could press any key to exit. So I pressed a key. Instead of exiting however the program started trying to program the BIOS flash. It quickly locked up, and after I cycled power I got no response at all from the computer.
I found out once I tore down the machine that I had an original Dell (a.k.a. R1) motherboard. The incomplete BIOS load for the R2 completely confused it, as the embedded controller wasn’t recognizing the power button or keyboard for Crisis rescue (FN+B). It wouldn’t do anything at all. Time to find the flash memory that stores the configuration information.
A little examination revealed that the low level functions on this motherboard are managed by an ITE IT8512E embedded controller. This device controls typical BIOS functions like ACPI, fan PWM, keyboard controller/scanner, PS2 input from the touchpad, etc. The controller consists of two domains, the host processor (BIOS) and an 8032 microcontroller (EC). It is not entirely clear from the datasheet how the two domains are integrated; I’m not sure if it’s a logical separation or if there is actually two processors on the device. At any rate the two domains share a common internal flash memory that is mapped from the external flash ROM. On my board this external memory was an SST 25VF016B which is an SPI flash. › Continue reading
SPI programmer for SST25VF016B
Thanks to my M17x I needed a way to program an SST25VF016B. The 25VF016B is a 3.3V SPI flash and I didn’t have anything that would program it. Thanks to some code I found at Sergey Malinov’s website I was able to build a programmer for this chip.
I built Malinov’s code in Linux. I also found some C code for driving the chip on Microchip’s website, but I didn’t use it. It is written for the Keil compiler. There is also Verilog code if you feel like doing this with a programmable logic device.
Malinov’s code uses a parallel port. Based on my CNC experience, I know it is really easy to kill a parallel port so I made my own interface for the parallel port to the flash. The buffer I used is a TI CD74HC366QDRQ1, a high-speed inverting three state buffer. Here is the schematic diagram.
The SPI programmer code runs on the command line. The options are read, write, id, status, and erase with read/write requiring a filename argument. To program a device you must first erase it or the data won’t be written correctly. Then write the image to the chip and verify it with read. You can use the “diff” command in Linux to verify the memory contents. There is also dhex, a nice program for verifying two binary files side-by-side.
Sony VAIO FW series laptop battery hack
I’ve been trying to find a battery solution for my VAIO laptop, as I like the computer but the battery is toast. I can’t find anything that isn’t made in China and requires some third party BIOS flash to fool Sony’s lockdown battery check. Since I haven’t been able to find anything I decided to risk just changing out the cells in the original battery.
I bought a battery from Amazon and of course it wasn’t recognized by my laptop. So I tore it and the original battery down. They are pretty similar. Just remove the cells from the new battery and solder them into the old battery. Since the cells will have a charge, be extremely careful when desoldering and soldering on the controller board.
After putting the old battery back together with the new cells, it was recognized by my laptop. I did a couple complete charge / discharge cycles, and got about 3-4 hours of runtime on the batteries. The only problem I am having is that the charging controller appears to be preprogrammed for a particular voltage level, as the battery percentage is always a little off and the battery status is always “charging”. It appears to be looking for a cell voltage level that the new cells never hit. I assumed that the algorithm would be adaptive but it appears not. I’ve done probably ten full cycles now and the numbers are always the same.
*What I’ve figured out so far: the controller is a Renesas R2J240F10. It uses SMBus to communicate with the motherboard, which is near enough to I2C that I can use I2C to sniff the bus. However, without the chip datasheet I can’t do much with it since I don’t know how the data is mapped. I need the datasheet to be able to figure out what values to replace in the EEPROM.
**I’ve also figured out that the cells in the pack (SE US18650GR) are of the base type 18650 but 18650 must just be a generic specification because you can find a bunch of different voltages and chemistry for that number. Charge cutoff in particular would be important. I’ve measured the cells of both new and old batteries after resting for a few hours and they are within 0.01 volts. So I still don’t know whats going on, and not sure if buying the proper Sony batteries will help me either.
***I think the controller board itself is failing, since I put the original cells back in and they aren’t being charged even though the computer is reporting they are charging. Too bad I don’t have a schematic. I gave up and bought a used OEM battery.
Fix your Keurig – again
So my Keurig decided to die again – this time it just started randomly brewing water onto the counter. The power switch didn’t work, so it got unplugged and when I plugged it back in the display just blinked “NOT READY”. It never became ready, and I was annoyed about the thought of having to shell out the cash for another one when this thing seems to break a lot anyway. So I ripped it apart to see if I could fix it. Turns out I could, and it was just a ten cent NPN transistor at fault.
You have to completely tear down the machine to get to the control board. It’s actually a bit of a complicated affair considering that it’s really just a fancy water heater. The controller board is based on a PIC16F917. There are three other boards, one for the pressure sensor, one for the display, and an input power filter. The offending part in my case was on the back of the controller board. I did a little reverse engineering and figured out that the burnt transistor was an NPN, and controlled the valve that bled air pressure when the brewing cycle was finished, before the water tank is refilled. › Continue reading
Breathe life into your Xoom
A few months ago I bought a Xoom and have mostly been disappointed with it. I use it mainly for internet, which is slow on the tablet plus the interface and keyboard are laggy. There are other problems as well, like the “recent apps” button that doesn’t remember certain apps like the browser and I’ve found if you leave the device on for more than about a day applications start to behave oddly.
I’ve been thinking hard about selling it because I didn’t think that rooting it and installing a tweaked ROM was going to be enough to fix it. I decided to try anyway with the new Android 4 (ICS) release. It only took about five minutes using the Xoom with ICS to realize how wrong I was and how good Android 4 is for the Xoom. Everything is better.
As usual with hacking all things mobile, you will be heading over to XDA if you want your Xoom to behave like it should. I’m writing a quick tutorial here since the information is pretty spread out on XDA. I had a couple issues that had me searching through pages of threads, so this is what worked for me. › Continue reading
PIC32 Ethernet Starter Kit and MPLAB X
I picked up Microchip’s PIC32 ethernet starter kit in order to check out their 32-bit processors as well as to get started on embedded web servers. The free TCP/IP stack from Microchip was my motivation, since it can be used on any of their chips, including the 8-bit versions. I also was interested in the C32 compiler, since it is free. I used MPLAB X for the test, along with the downloadable Microchip application libraries. I have been using MPLAB X for PIC18 development, and I really like it. It’s a nice IDE.
This review will cover getting the SKDE up and running with the TCPIP Demo App from the application libraries in MPLAB X.
Other Stuff
Recent Posts
Archives
- May 2019 (2)
- April 2017 (3)
- October 2015 (1)
- May 2015 (1)
- March 2014 (2)
- December 2013 (1)
- July 2013 (1)
- November 2012 (1)
- October 2012 (4)
- September 2012 (1)
- August 2012 (3)
- June 2012 (1)
- March 2012 (1)
- February 2012 (1)
- January 2012 (1)
- October 2011 (3)
- July 2011 (1)
- June 2011 (3)
- May 2011 (2)
- April 2011 (1)
- December 2010 (1)
- August 2010 (1)
- July 2010 (3)
- April 2010 (2)
- March 2010 (2)
- January 2010 (2)
- December 2009 (2)
- October 2009 (2)
- September 2009 (1)
- August 2009 (15)