Sign in

username:

password:



Not a member?

Search Comp.Arch.Embedded



Search tips

embedded by Keywords

68HC11 | 68HC12 | 8051 | 8052 | ARM | ARM7 | Asic | AT91 | AT91RM9200 | Atmel | AVR | AVRStudio | Bootloader | CFP | CompactFlash | Cygnal | Cypress | Dataflash | DSP | eCos | EEPROM | Embedded Linux | Emulator | Endian | Ethernet | Firewire | FPGA | Freescale | GCC | GNUARM | GSM | H8 | HDLC | I2C | Infineon | Interrupts | Java | JTAG | LCD | LED | LPC2000 | MCU | Microchip | MMC | MPLAB | MSP430 | PC104 | PCB | PCI | PCMCIA | PowerPC | Rabbit | RS232 | RS485 | RTOS | SBC | SDRAM | Sensor | SPI | STK500 | UART | UML | USART | USB | Verilog | VHDL | VxWorks | Xilinx

Ads

Discussion Groups

See Also

DSPFPGAElectronics

Discussion Groups | Comp.Arch.Embedded | Reverse Engineering A Button Interface

There are 3 messages in this thread.

You are currently looking at messages 0 to 3.

Reverse Engineering A Button Interface - eeboy - 2009-07-02 19:07:00

I am reverse engineering a circuit so that I can interface to it and
electronically control the button input. I have successfully accomplished
this on an earlier version of the product, however, the next
revision/generation is giving me issues. I wanted to bounce this off the
group...

The keypad for both versions is 12 buttons with 3 commons (15 pins total).
The keypad is an FPC which plugs into a ZIF socket. I interface at the
point of the ZIF socket. There are no components on the FPC. It consists
only of the 15 pins wired to membrane switches.

The current version (the one that I can interface to) is very simple in
that the 3 common lines are tied together and are at ground potential. The
remaining 12 pins are all routed back and individually pulled high. This
makes interfacing very easy as I simply route the 12 pins to 12 N-Channel
MOSFETs tying the drain to the pin and the source to any of the commons
(ground).

The newest version has 3 commons. Each common is routed to a group of four
buttons. So, common 1 is associated with buttons 1,2,3 and 4... and so on.
The commons are at roughly 3VDC and the remaining 12 pins are at
approximately .65VDC. Neither has a low impedance path back to the systems
positive rail or ground. The target circuit is very complex (>6 layers) so
I can't trace anything around the board.

I can physically short a pin to the appropriate common and the
functionality associated with that button works. I attempted to control the
functionality by wiring in both P and N channel FETs (separately
obviously). They both work on some buttons and not on others. For example,
in the set of buttons (4) associated with common 1, button 2 and 3 may work
reliably all the time but buttons 1 and 4 will work sometimes yet trigger
the functionality associated with buttons 2 and 3 at other times.    

I can't seem to wrap my head around what they might be doing in the target
circuit. The only reason I can see for them to change the interface is to
minimize I/O count... but I don't see how this would achieve that goal.

Any suggestions?





Re: Reverse Engineering A Button Interface - Rocky - 2009-07-03 01:33:00

On Jul 3, 1:07=A0am, "eeboy" <ja...@jasonorsborn.com> wrote:
> I am reverse engineering a circuit so that I can interface to it and
> electronically control the button input. I have successfully accomplished
> this on an earlier version of the product, however, the next
> revision/generation is giving me issues. I wanted to bounce this off the
> group...
>
> The keypad for both versions is 12 buttons with 3 commons (15 pins total)=
.
> The keypad is an FPC which plugs into a ZIF socket. I interface at the
> point of the ZIF socket. There are no components on the FPC. It consists
> only of the 15 pins wired to membrane switches.
>
> The current version (the one that I can interface to) is very simple in
> that the 3 common lines are tied together and are at ground potential. Th=
e
> remaining 12 pins are all routed back and individually pulled high. This
> makes interfacing very easy as I simply route the 12 pins to 12 N-Channel
> MOSFETs tying the drain to the pin and the source to any of the commons
> (ground).
>
> The newest version has 3 commons. Each common is routed to a group of fou=
r
> buttons. So, common 1 is associated with buttons 1,2,3 and 4... and so on=
.
> The commons are at roughly 3VDC and the remaining 12 pins are at
> approximately .65VDC. Neither has a low impedance path back to the system=
s
> positive rail or ground. The target circuit is very complex (>6 layers) s=
o
> I can't trace anything around the board.
>
> I can physically short a pin to the appropriate common and the
> functionality associated with that button works. I attempted to control t=
he
> functionality by wiring in both P and N channel FETs (separately
> obviously). They both work on some buttons and not on others. For example=
,
> in the set of buttons (4) associated with common 1, button 2 and 3 may wo=
rk
> reliably all the time but buttons 1 and 4 will work sometimes yet trigger
> the functionality associated with buttons 2 and 3 at other times. =A0 =A0
>
> I can't seem to wrap my head around what they might be doing in the targe=
t
> circuit. The only reason I can see for them to change the interface is to
> minimize I/O count... but I don't see how this would achieve that goal.
>
> Any suggestions?

Try using a CMOS analog switch such as the CD4066 or the more modern
version 74HC4066

Re: Reverse Engineering A Button Interface - Mike Harrison - 2009-07-03 03:29:00

On Thu, 2 Jul 2009 22:33:21 -0700 (PDT), Rocky <R...@gmail.com> wrote:

>On Jul 3, 1:07 am, "eeboy" <ja...@jasonorsborn.com> wrote:
>> I am reverse engineering a circuit so that I can interface to it and
>> electronically control the button input. I have successfully accomplished
>> this on an earlier version of the product, however, the next
>> revision/generation is giving me issues. I wanted to bounce this off the
>> group...
>>
>> The keypad for both versions is 12 buttons with 3 commons (15 pins total).
>> The keypad is an FPC which plugs into a ZIF socket. I interface at the
>> point of the ZIF socket. There are no components on the FPC. It consists
>> only of the 15 pins wired to membrane switches.
>>
>> The current version (the one that I can interface to) is very simple in
>> that the 3 common lines are tied together and are at ground potential. The
>> remaining 12 pins are all routed back and individually pulled high. This
>> makes interfacing very easy as I simply route the 12 pins to 12 N-Channel
>> MOSFETs tying the drain to the pin and the source to any of the commons
>> (ground).
>>
>> The newest version has 3 commons. Each common is routed to a group of four
>> buttons. So, common 1 is associated with buttons 1,2,3 and 4... and so on.
>> The commons are at roughly 3VDC and the remaining 12 pins are at
>> approximately .65VDC. Neither has a low impedance path back to the systems
>> positive rail or ground. The target circuit is very complex (>6 layers) so
>> I can't trace anything around the board.
>>
>> I can physically short a pin to the appropriate common and the
>> functionality associated with that button works. I attempted to control the
>> functionality by wiring in both P and N channel FETs (separately
>> obviously). They both work on some buttons and not on others. For example,
>> in the set of buttons (4) associated with common 1, button 2 and 3 may work
>> reliably all the time but buttons 1 and 4 will work sometimes yet trigger
>> the functionality associated with buttons 2 and 3 at other times.    
>>
>> I can't seem to wrap my head around what they might be doing in the target
>> circuit. The only reason I can see for them to change the interface is to
>> minimize I/O count... but I don't see how this would achieve that goal.
>>
>> Any suggestions?
>
>Try using a CMOS analog switch such as the CD4066 or the more modern
>version 74HC4066

..or two back-to-back CMOS multiplexers