# Interfacing with unknown MCU (COB), unusually high current on input pin

I recently got an oscilloscope with a logic analyser and their first mission was helping me in reverse engineering the communication protocol between two 15-20 years old unknown MCUs (COB). The goal is interfacing with one of them using an Arduino. My issue is that the currents flowing through the input pins of the unknown MCU (clock+data) are unusually high. I expected almost zero current because input pins are supposed to be high impedance.

In its original environment the MCU receives a 10-20kHz clock signal from the other unknown MCU and that requires 4-8mA current (these measurements might not be very accurate though). The current seems to be directly proportional to the frequency. Nothing too surprising but I never had to measure the current flowing through a digital input pin in my previous much simpler Arduino projects.

I bitbanged the protocol in the Arduino IDE and my teensy LC (MKL26Z64VFT4 Cortex-M0+ 3.3V) can communicate with the unknown MCU: a 10-20kHz clock signal needs 3-6mA current. However, an Adafruit ItsyBitsy (ATmega32U4 3.3V) can't send the clock signal to the unknown MCU. Trying to drive the output LOW drops the voltage from 3.3V to 2.4V and the current is a steady 27mA.

Can those input pins be (partially) damaged? What makes it possible for my ARM-based MCU (teensy LC) to interface with those input pins? Can this damage the ARM MCU in the long term? (I guess the instantaneous currents are higher than my measurements.)

• First, what do you mean by "COB"? Second, is the input going directly to a microcontroller, or is it going into a board, or what? 8mA and tens of kHz would be about right for an older optocoupler input. Jul 8 at 5:18
• Could be a 4 to 20mA current loop. What do the two unknown devices the MCU's drive do? Jul 8 at 5:39
• @TimWescott COB = chip-on-board. The unknown MCU is on a small PCB in a game controller. It reads sensors (mostly buttons) and sends the collected info elsewhere in digital format.
– AnnC
Jul 8 at 6:08
• @StainlessSteelRat Is this loop caused by the internal structure of the ATmega32U4 because the ARM-based MCU seems to work in the exact same situation. My teensy LC (an Arduino-compatible board with ARM-based MCU) powers the unknown MCU and polls it for info through GPIO pins. The second unknown MCU that originally did the polling has been disconnected and isn't part of my setup.
– AnnC
Jul 8 at 6:15
• Likely a current modulated, bit-banging protocol. Or maybe current modulated SPI? Current modulation makes sense for game controllers, since it gives far more rugged signals, less vulnerable to oxidation, EMC and so on. Jul 8 at 6:49

1. The only reasonable explanation for the high current is that it was designed for a long cable with a 100 Ohm load to reduce ringing.

2. Driver impedance differences due to supply Vdd max. is why the Arm worked with this 50 ~ 100 Ohm load to pull the Vol below 50%.

I can prove:

   Arm Cortex    1.65V ≤ VDD ≤ 3.6V   =   " 25 Ohm driver nom."
Arduino ATMega 2.7V ≤ VDD ≤ 5.5V   =   " 50 Ohm driver nom."
+/-25%


Using a linear approximate of logic from KVL , from the voltage drop, you can estimate the unknown load or source impedance. In this question, there is a difference is source resistance.

During transition both Pch and Nch drivers are active ( during Vgs transition). This causes somewhat of a shoot thru current spike and low impedance helps to drive load capacitance at higher speeds. Thus, when CMOS families are designed to go faster with lower RdsOn, this restricts the Vdd max. due to Pd self heating.

Zol = Vol /I
Zoh = (Vdd-Voh)/I

Keep in mind Vol,oh {max} in datasheets computes {max} impedance. Similar 3.6V discrete logic, show more details (min, typ, max) indicates +/-25 tolerance or more. However, reducing Vdd from max also raises RdsOn.

The Electrical properties specs for uC, MCU's is always at the end of hundreds of pages of specs , just before the physical dimensions.

Many examples support this undocumented behaviour computed by Zo for logic.

• Thanks for your answer. The two unknown MCUs are indeed in separate enclosures connected by a 1.5m long cable. The wires go directly to the GPIO pins on both sides of the cable. There are some filtering capacitors and 10k pulldowns too. I started learning electronics only a few weeks ago (haven't finished reading my first electronics book) and didn't know that a "short" cable can have so big impact on design. I tried to look for answers (google and datasheets) but found only more questions due to my lack of experience.
– AnnC
Jul 8 at 7:36
• There could also be an ESD generated faulty load Jul 8 at 8:55
• Accumulated ESD damage was one of the first possible explanations I thought of. However, the original cable can be unplugged so I'd expect the GPIO pins to have at least some protection against ESD. The MCUs received some punishment from me too during the investigation but everything seems to work as before and my measurements still give the original numbers. TBH, I was prepared for failure and frying things, that's why I picked an old game controller as the subject of my early experiments. :-)
– AnnC
Jul 8 at 9:29
• When the cable is disconnected , the tribolectric actions cause the inner layer of plastic to create a voltage on the conductor. We used to see many SCSI drivers get blown in Final test of peripherals in production, until we in Test Engineering enforced a practice to discharge the conductor to frame before connections. Jul 8 at 14:12
• That cable was probably unplugged hundreds or thousands of times during the life of the game controller. It seems to be a cheap piece of equipment so its design might not be the best. ESD is a tricky problem. I bought a basic protection kit with a portable mat but found it very uncomfortable and haven't used it so far. During my first Arduino projects I hoped to get away with 50% relative humidity and no carpet. For the long term I'll integrate some form of protection to the tabletop and put a strap on my leg instead of my wrist.
– AnnC
Jul 8 at 23:00