TransWikia.com

Touch screen driver module - Determine comunication protocol

Reverse Engineering Asked by Justin Wylie on May 10, 2021

I have taken apart an old non-functional Lenovo IdeaCentre (B320) computer.

I would like to get the glass touch panel to ‘work’ (I would consider anything from simply being able to sniff the x,y coordinates to be ‘working’).

There is a single cable coming from the glass, this cable plugs into a module. The module has only one other connection. This connection has four wires and is connected to the motherboard of the computer. The black and red wires are ground and 5V respectively, this I confirmed by powering on the computer and measuring. The remaining two wires are a mystery, they are (for what it’s worth) brown and orange.

Following the traces on the module, I can see they are connected to an STM32F102C6 (LQFP48). The two wires are connected to pin 32 (brown) and 33 (orange). I downloaded the datasheet for the MCU, from this I can see pin 32, 33 corresponds to PA11 and PA12 respectively.

PA11 has the alternate function ‘USART1_CTS/USB_DM’

PA12 has the alternate function ‘USART1_RTS/USB_DP’

I did some googling and it seems that CTS and RTS are only used for data flow control, considering there are no other data wires I assumed the USB protocol is the most likely (even though the wire colors are not conventional to USB). I wired up a USB cable and plugged it into my computer and nothing happened (absolutely nothing).

I’m stuck for ideas now. Could it be performing some kind of communication over the USART pin functions or possibly even some kind of bit-banged protocol over the GPIO’s? Perhaps the module is dead and that’s why the USB isn’t detected by the computer.

What further steps could I take to reverse engineer this module?

Top side of the module, cable from glass pannel detatched

Under side of the module, STM MCU visible

2 Answers

The manufacturer's website suggests that at least their recent touch screen controllers are either serial and/or USB.

The controller picture has the laptop model name (B320) on it which suggests it's a custom version produced by Elo for Lenovo.

Looking at the driver files for hardware devices can be one way of understanding how they work. The Windows XP drivers can be found here on Lenovo's website.

This download actually contains both USB and Serial drivers, but these are not Lenovo specific. Instead it looks like the file EloOptions.ini is used to specify exactly which driver to install. This file is clearly customized for Lenovo and confirms that it's the USB driver that is needed.

[Setup Options]
; For Lenovo, set all but USB to 0
AutoDetect = 0
AllowInstallApr = 0
AllowInstallSerial = 0
AllowInstallUsb = 1
CalibrateAfterInstall = 0
BaseMode = 0

The EloMTUsb.inf file also suggests that it's installed as a USB HID class device. If so, there's a good chance that you won't have to do too much reverse engineering as it should follow the relevant USB HID standards.

The Readme.doc file list various controller part numbers which might also be helpful.

Correct answer by Ian Cook on May 10, 2021

I'd say that it is more likely to be a faulty USB connection than real use of CTS/RTS.

If you have a signal analyzer (like Saleae Logic) and can record a signal from the USB_DM or USB_DP, you will be able to easily tell if this is USB, if there is some signal at all.

Answered by Yotamz on May 10, 2021

Add your own answers!

Ask a Question

Get help from others!

© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP