Anticheat circuit?

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a device that gets its power from a main circuit. When the device is connected the MCU has to go into special mode to use it. This could be done with a simple switch, but then that mode could be enabled anytime, and that would be sort of a "cheat mode" if the device isn't connected. (It will be a game)
Is it possible to instead use the powerlines to detect if the device is connected or not?
I want a signal to the MCU (high or low) when comm is connected.
The problem is that the detector may not drop the voltage supplied more than a few mV, so I guess a optocoupler can't be used. At least not any I know of.
Any ideas? My hair is turning grey...

The XXXXXX is the connector.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Typically, the way something like this is done is to have an I/O line on the MCU set as an input and pulled up so that it normally reads high. The cable that connects the device to the main circuit has one line which is connected to ground on the device on one end and the I/O line on the MCU end. Thus, when the device is connected, the I/O line is pulled low and sensed by the MCU. When the device is unplugged, the line is pulled high by the pullup. Depending on the MCU used, the line could be connected to an external interrupt pin such that you would get an interrupt when the device was either connected or disconnected. The downside to this approach is that it dedicates a line in the cable to this function. If you don't have that spare line, this approach won't work.

Dave

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you, but I have thought of that already. All pins on the connector and the cable are used, so I need something else.
I've tried using diodes from the MCU and Vcc, but the Vcc-line has no resistance compare to the GND coming from the device. So the Vcc becomes a to effective pullup and the device can't pull the input low.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I need to clear up some vagueness. Your device is an HID (human interface device)? Your Main board contains the MCU? The connector between the MCU and the HID is full, but you need a way to identify that the HID is connected.

Doesn't the HID produce a signal that isn't present when it's missing? Challenge/response, voltage, pulse, etc? You mention comm, does this mean 'communication'? What are the comm voltages? Are they different when the HID is connected? Can you use the comm (serial?) signals to activate the mode?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The "device" is simply a RS232- and ISP-interface on a single board. It is connected to the "mainboard" via an RJ45-connector (standard TP-network cable). The connector has these connections: Vcc (=5V), Gnd, MISO, MOSI, SCK, RESET, Tx (TTL/CMOS) and Rx (as Tx).

What mode the MCU is in when doing ISP won't matter since reset will be pulled low (active), and it will not be used ingame anyway. But the RS232 is another matter. I've thought about starting it with such a signal as you mneary suggested, but the most convenient and effective way was to not have the UART running when not being used.

---

Now I've rewritten the above a couple of times to clear my head and I see no reason why it can't be woken up by a RS232-signal... I'll take that thought to bed and dream about the solution!

But I still think an electrical solution would be neat...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What devices are you using for RS232 to TTL conversion? Maxim have a chip (I'll look up the part number if you're interested) which provides a signal when a "valid" RS232 level is detected on the RX data line. I use it to determine when unit is connected to a PC's serial port for parameter downloads.

John

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Part number is MAX3221.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks! I'll check it out and see if it is what I need!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I finally got it to work! The solution was to rewrite the UART-handler and include the receiver code in the main loop.
That way it will not have anything that interferes with receiving and thus not need any enabling/disabling.
A big thanks to all of you!