How to debug PS/2 protocol?

32 posts / 0 new
Last post
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The attached Codevision code is for an Atmega32a-based accelerometer mouse that interfaces to the computer via PS/2 protocol. (Notice this is not PlayStation2, it's this: http://www.computer-engineering.org/ps2protocol/)
I have been able to show that the ADC portion works, which is dataFromMouse(), however I'm still not getting any mouse movement. All the outputs of the uC remain at +5V (idle state) all the time.
I honestly don't have a clue where to start debugging this huge program, other than putting LED lighting commands in strategic places. If anyone has any prior experience with this, I would greatly appreciate any suggestions on how to approach this.
Thanks in advance.

I've attached the file with the code, as well as the schematic.
Some differences in my setup:
* Instead of a crystal, I'm using int.RC 8 MHz.
* Not using the buffers.
* AREF has a 100nF capacitor to GND

Also I should mention I don't have an LCD, though there's code for it.
I got a PS/2 cable from an old mouse and am using it to go directly from the uC to the computer. (I don't think the cable is the problem, I made sure the mouse worked before I cannibalized it.) I was able to match the wires to the pins. No converter should be needed in this case. This is an HID device and the Windows built-in driver is supposed to recognize it.
When I google, all I get is PlayStation2, unfortunately that's not what I'm looking for. :?

(As an aside, when I click on the Msg Icon or Smiles buttons under the quick reply box, I get a window that says "Hacking attempt1".)

Attachment(s): 

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

Here is my understanding of what this code is supposed to do. Rather than regular PS/2, which has 3-byte packets, this uC is emulating a Microsoft Intellimouse, with 4-byte packets. Packet is shown here:
http://www.microsoft.com/whdc/archive/mcompat.mspx#ECF

A PS/2 byte has 11 bits:
0 - - - - - - - - 1
start,(8 bits of data, LSB first),stop

Rx/Tx: 4 states

(1) Idle: outputs float high
(This is where I'm stuck at, all the time)
*Mouse has something to send? Go to (2)

(2) Busy: -set flags (Rx or Tx)
-Host inhibit: pull clk low for >100 us
(clk period=80us, that is, 12.5 kHz)
* Mouse checks for this condition by seeing if clk. output is high but reading low. If true, go to (3)

(3) Inhibit: -Stop all xmit
-clk,data=1
-(If byte interrupted, resend later)
*Host request to send (pull data line low after inhibit; this tells the mouse to start the clock (high first)). Go to (4)

(4) Request: -will go back to Busy in 1 clock cycle
-Clock low: host send PS/2 byte (11 bits)
-High: mouse send ACK (0xFA) after stop bit
-Low: Host reads ACK

* State changes are caused by timer 1 interrupt.

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

As a general approach, I'd write the simplest code possible to output some fixed mouse movement (e.g. up and to the left, repeat). Get that working before moving on to anything else.

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

snickersnee where'd you get the code / circuit from ( No access to explanation of the design ? ) ? You're trying to build a PS/2 mouse from the ground up ? HOW do you KNOW this design even works ?

Like I said in your previous topic, you can't debug if you don't understand it. So ask yourself how much of this code you get,and verify it works up to there. Understand it step by step. I'd get the usart code to work so you can confirm correct PS/2 codes are generated before hooking up to PS/2 port.

There's a PS/2 KEYBOARD effort in pjt. forum. Atmel has app. notes on this.

May help:
http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2002/jew17/index.html

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

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

Quote:
I'd get the usart code to work

There's usart code in it? I didn't see that

Let me find where I got the code from, hold on.

The hardware design is an open-collector interface as discussed in the link in my first post. However, this version is simplified; instead of transistors, it uses 600 ohm resistors.

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

snickersnee wrote:
There's usart code in it? I didn't see that.
The usart is implemented in code. (Hardware usart isn't used.)

Look at the ISR clockGenNrecvNtrans(void) and you'll see the data clocked out on DATA_OUT, defined as PORTD.6.

Take the advice from IndianaJones. You really need to understand how this code works in order to debug it.

Your idea of using spare pins to give debug info is good, but you'll need to manage the flash duration if you want to see the LED flash. If you have a logic probe with pulse detection, you could turn a pin on then off immediately without regard for duration.

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

Sorry about the uart ref. ( ok it's code to emulate the PS/2's DATA / CLK ), then use the lcd to verify vars.

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

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

Having a scope to reveal what's happening on the data and clock lines would help.
If you don't have one this might be an easy way to get a good enough one for your needs.
http://www.zeitnitz.de/Christian/scope_en

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

Port D.1 (output clock) is also the TXD pin for the USART, but I don't see any USART initialization such as UBRR, UCSRB, etc. That's why I'm confused that you guys keep talking about USART.

Quote:
use the lcd to verify vars

I noticed the lcd code commented out...Ordered one, don't have it yet.

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

Are you sure you got the data transfer directions right? When you describe your state machine, it looks like what the HOST does, not the MOUSE. A bit. It is confusing.

Okay, first of all, the mouse should report only standard 3-byte packets, unless the HOST sends the mouse the correct magic sequence which the mouse recognises and switches to the extended 4-byte protocol.

But even before that, mouse should be in a mode it will not transmit movement packets, unless it receives a command that allows it to enable movement packet transmissions.

Nevertheless, 3 or 4 byte responses from mouse, bytes are sent alike.

1) if both lines are high, mouse can start transmission if there is something to send. Mouse is always the device that drives the clock pulses to transmit bits, no matter which direction the bits are transmitted.

2) if HOST pulls clock low, then, mouse is not able to start transmission until HOST lets clock high again. This is the inhibit state.

3) if HOST pulls data low, it is a sign of request and then mouse must start clocking data out from the host.

Now there is a catch, the HOST may just do a request by setting data pin low without inhibit, or, it may first set clock low to inhibit mouse, then set data low, and release clock, so the mouse sees request when coming out of inhibit mode.

And also I honestly don't understand why put 600 ohm resistors there. It will work without any series resistors, or to be safe, something max 100 ohms should be put there. Pulling the clock/data lines through 600 ohms may not be strong enough to pull the voltage to sane logic low level of about 0.6V.

Speaking of logic levels, what kind of pull-ups you have on the clock/data lines (if any?). If you have something between 2k and 15k you should be fine.

Are you sure you drive the clock and data pins in open-collector mode, not push-pull mode? You are never ever allowed to set the pins as high outputs, only inputs or low outputs.

Pages