Weekend Probing: Keweisi KWS-V20 USB Tester IC Connections

After doing a quick review and test of the Keweisi KWS-V20 USB tester, the whole issue of the unknown microcontroller IC, the EEPROM which holds the accumulated charge and the LCD display really bugged me. I thought of the possibility of somehow leveraging them for data logging purposes, but aside from that, I didn’t really know how it worked.

As a result, I took a first step towards a better understanding of how the unit worked, through a nice and thorough probing.

Result

Normally when I go about trying to reverse-engineer something, it’s a fairly simple product that’s cheap and simple with clear traces which can be followed. The Keweisi frustrates this somewhat, because it’s got a black PCB which has terribly poor contrast between traces and planes, it is double sided and has many through-hole vias, and it has a gob-top mounted controller and LCD I’d rather not desolder.

As a result, a different approach was taken, to examine the voltages and signals around the U1 microcontroller and check for resistance/continuity to try and trace out the functional elements of the circuit.

abridged-schematic

I’m sorry to those who might not like my hand-drawn schematics which are a little messy, but it’s quick and easy for me to draw them and I feel it’s a more efficient way to express the process.

In essence, I first ran the unit with a small load and started probing around the pins using my Picoscope 2205A. Of course, that only lets you see the voltages while the unit is in operation, but doesn’t really tell you the connections. With some experience, the sort of connections can be guessed by the types of signals seen.

Note that the drawing above is necessarily simplified and may contain errors. I won’t be held responsible for any damage incurred directly or as a consequence of attempting to, or actually being able to use the data.

The first thing I noticed was that many pins had a low voltage level of ~0.1v, but the only true ground pin with no potential was pin #4. As a result, that’s almost a guaranteed confirmation that the pin is ground.

Chips often like to have symmetrical layouts, so I checked the pin opposite and found 3.3v, which is likely to be Vcc. This implies that pin #11 is Vcc.

Pin #12 and pin #13 were a team, and were continually blurting out data. Pin #12 had a number of regular clock bursts spaced slightly, followed by a long pause, and Pin #13 had the corresponding data in the same temporal pattern. This is definitely an I2C bus, and due to the constant nature of the data, it is highly likely to be for the LCD.

Looking for the I2C connections to the EEPROM, I decided to probe the EEPROM’s SDA and SCL lines for life. Strangely, they were mostly high (i.e. idle). Eventually, my patience paid off, as I had the feeling that eventually something would happen – and it did. Every 30 seconds, a sequence of writes is performed to the chip, which otherwise remains idle. Scoping around, I found the pins with the matching data (pin #7) and clock (pin #6). As a result, we can conclude whatever this microcontroller is has two I2C buses and that it’s likely that the EEPROM endurance will be about 30 times better than estimated based on the no-rotation case. I suspect the storage is not being rotated, but I didn’t thoroughly examine this.

Pin #8 and #10 were both somewhat mysterious, being at 3.3v all the time. After probing about and toggling the only input available, namely the reset button, I found that pin #8 is the reset line which is pulled down by the push button. I didn’t go as far to try and identify whether the pull-up was internal or external, but I don’t think that really matters too much anyway. This left pin #10 somewhat mysterious, for later examination.

Pin #9 had a relatively consistent rectangular wave of 248.7Hz at 73% duty cycle continually running. I’ve marked this as “CLOCK?” as I’m not entirely sure, but it could be a clock signal that’s used to drive the LCD multiplex, or segment inverter?

Pins #1, 2, 3, 5, 10, 14 were still somewhat ambiguous, so I powered down and started to trace the connections by continuity. I knew from past experience that some of these pins had to be used for voltage sensing and current sensing, so I decided to first try and find the voltage sensing pin.

This turned out to be Pin #1, with a 22K resistance measured to Vcc and a 2K resistance measured to ground. This forms a 1/12th voltage divider. We now know that Pin #1 on this microcontroller has to be an analog input.

Tracing the current measurement pins required testing for resistance between unknown pins and the shunt resistance. This turned out to produce two pins, which is unusual, and suggests the use of a differential voltage measurement (rather than just tying one end to ground). Regardless, pin #2 and pin #5 each appeared to have 0 ohms to one end of the shunt respectively, thus both are likely analog inputs as well.

Pin #3 was a mystery. I couldn’t see where its connection went on the PCB, but it may just be an unused pin, with the 0.1V measured on it being “stray” coupled voltage. Pin #14 was another mystery pin, which also had such a stray voltage, but I’m not sure whether this one is non-connected as well. Maybe if I was willing to desolder the chip and the LCD, we could have a better look.

The strangeness of having pin #10 at 3.3V was solved when I traced its continuity to the EEPROM’s Vcc line. It seems that it’s being “abused” as an output to power the EEPROM, maybe as this may allow for the unit to reset the EEPROM by toggling the pin. The EEPROM’s write-protect pin is likely to be tied to a fixed voltage level, as it’s not being used, but I didn’t draw that in.

Conclusion

The result of a nagging desire to know more about the microcontroller and the data flows led to a quick weekend probing which revealed quite a few interesting results. Of course, this is only a first step, as we only know something about the physical connections. Examining the data flow will take some more sophisticated work – namely soldering on some more permanent connections to pin #6, 7, 12 and 13 and using a logic analyzer to see what’s actually being transacted over the bus.

Hope this information comes in handy if someone else is interested in having a play with their unit.

About lui_gough

I'm a bit of a nut for electronics, computing, photography, radio, satellite and other technical hobbies. Click for more about me!
This entry was posted in Electronics and tagged , , . Bookmark the permalink.

2 Responses to Weekend Probing: Keweisi KWS-V20 USB Tester IC Connections

  1. Mark says:

    The LCD interface may not be I2C. I have seen LCD drivers that take a clock and data but are not I2C. You could hook a something like a Bus Pirate up to it and see. Also they may be bit-banging one (or both) of the I2C interfaces in software and not using a hardware I2C peripheral.

Error: Comment is Missing!