• 0
CPerez10

ps/2 (USB) keyboard clock not starting

Question

I know this topic has been started before, but I wanted to program my own driver to communicate with the keyboard as a learning experience.

Currently trying to get data from my USB keyboard or getting the clock going. I used this guide: http://www.burtonsys.com/ps2_chapweske.htm

According to the guide, I simply need to leave the clock high for 50 microseconds. I've tried various permutations of manipulating the clock and data line on the rising/falling edge, but not a single blip that I haven't caused. I'm using waveforms to see if any of the lines move. Only my div clock does (10Khz).

 

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
use ieee.std_logic_unsigned.all;

entity KeyMain is
    Port (clk : in STD_LOGIC; 
			USB2_CLK : inout  STD_LOGIC;
         USB2_DATA : inout  STD_LOGIC;
         led : out  STD_LOGIC_VECTOR(7 downto 0);
			dio0 : out STD_LOGIC;
			dio1 : out STD_LOGIC;
			dio2 : OUT STD_LOGIC);
end KeyMain;

architecture Behavioral of KeyMain is

	component clk_div is
   port ( CLK_IN : in  STD_LOGIC;
           CLK_OUT : out  STD_LOGIC);
	end component;

	signal key_buff : STD_LOGIC_VECTOR(7 downto 0) := "10000001";
	signal buff_counter : unsigned(3 DOWNTO 0) := "0000";
	signal temp : STD_LOGIC := '0';
	signal step_counter : unsigned(3 DOWNTO 0) := "0000";
	signal div_clk : STD_LOGIC;

begin

	clk_div_inst : clk_div
		port map(
		CLK_IN => clk,
		CLK_OUT => div_clk);

	process(div_clk, USB2_CLK)
	begin
	
	if falling_edge(USB2_CLK) then
		if step_counter = 1 then
			if buff_counter > 10 then
				buff_counter <= "0000";
				--key_buff <= "00000000";
			else
				buff_counter <= buff_counter + 1;
			end if;
		
			if buff_counter > 0 then
				key_buff(to_integer(buff_counter - 1)) <= USB2_DATA;
			end if;
		end if;
	end if;
		
	if falling_edge(div_clk) then
		if step_counter = 0 then
			USB2_CLK <= '1';
			--USB2_DATA <= '1';
		--elsif step_counter = 1 then
			--USB2_CLK <= '0';
			--USB2_DATA <= '0';
		--elsif step_counter = 2 then
			--USB2_DATA <= '0';
		end if;
		
		if step_counter /= 1 then
			step_counter <= step_counter + 1;
		end if;
	end if;
	
	end process;

	led <= key_buff;
	dio0 <= USB2_CLK;
	dio1 <= USB2_DATA;
	dio2 <= div_clk;
end Behavioral;

 

Share this post


Link to post
Share on other sites

9 answers to this question

Recommended Posts

  • 1

Could you put pullup constrains to both clk and data pins, because in the reference manual it says:

Quote

The clock and data signals are only driven when data transfers occur, and otherwise they are held in the idle state at logic ‘1’.

Try to modify like this:

NET "USB2_CLK"		LOC=K17	|	IOSTANDARD=LVCMOS33 | PULLUP;			#Bank = 1, pin name = IO_L40N_GCLK10_M1A6_1,	Sch name = USBH2-CLK
NET "USB2_DATA"	    LOC=L17	|	IOSTANDARD=LVCMOS33 | PULLUP;			#Bank = 1, pin name = IO_L40P_GCLK11_M1A5_1,	Sch name = USBH2-DATA

 

Share this post


Link to post
Share on other sites
  • 0

Took a look at the code. There's nothing there (or anywhere else) that indicates having to do anything in order to get the clock on the device going. In my latest attempt, I set the UCF file to include the clocks from both ports in the clock and data lines respectively (just to cover all my bases). I tried hooking up 3 different keyboards (all of which work and have various specs) to either side and looked at the clock. Not a blip. Here's a small snippet of the relevant code:

begin
	clk_div_inst : clk_div
		port map(
		CLK_IN => clk,
		CLK_OUT => div_clk);

	process(div_clk, USB2_CLK)
	begin
	
	end process;

	dio0 <= USB2_CLK;
	dio1 <= USB2_DATA;
	dio2 <= div_clk;
end Behavioral;
NET clk LOC=D11;
#NET USB2_CLK	LOC=K17;
#NET USB2_DATA	LOC=L17;

NET USB2_CLK	LOC=A12;
NET USB2_DATA	LOC=k17;

NET led<0> LOC=W3;
NET led<1> LOC=Y4;
NET led<2> LOC=Y1;
NET led<3> LOC=Y3;
NET led<4> LOC=AB4;
NET led<5> LOC=W1;
NET led<6> LOC=AB3;
NET led<7> LOC=AA4;

NET dio0	LOC=AB20; #BB1 etc.
NET dio1	LOC=P17;
NET dio2	LOC=P18;

Only thing I can think of now is that there's something wrong with my UCF file, but I also saw the lines going up/down when I was configuring them to get the clock started, so I kind of doubt it.

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)

Why are you using

NET USB2_CLK	LOC=A12;
NET USB2_DATA	LOC=k17;

You should use

NET "USB2_CLK"		LOC=K17	|	IOSTANDARD=LVCMOS33;			#Bank = 1, pin name = IO_L40N_GCLK10_M1A6_1,	Sch name = USBH2-CLK
NET "USB2_DATA"	    LOC=L17	|	IOSTANDARD=LVCMOS33;			#Bank = 1, pin name = IO_L40P_GCLK11_M1A5_1,	Sch name = USBH2-DATA

 

The correct ucf file for Anvyl is Anvyl_Master.ucf

Edited by Ana-Maria Balas

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)

I'm aware of the UCF constraint discrepancy, I mentioned that I used both the clocks in the clk/data pins to check both the clocks and ignore the data line (this way I could check both at once and cover my bases faster). If you notice, I have the correct values commented out. So this isn't the error.

Edited by CPerez10

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)

Didn't know those were pullup constrains, thanks for letting me know. Now the clock seems to tick regardless of whether I place the keyboard in though. And when I set the constraints to the values they should be for coding, it still doesn't work. Thoughts?

Edited by CPerez10

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)

How do you see the clock? Later edit: I saw that you are measuring it through dio. I didn't see the answer that the clock works with pullup constrains.It's good that the clock works now.

See this forum thread https://forum.digilentinc.com/topic/9382-anvyl-board-hidps2keyboard-interface/

The problem lays elsewhere. Are you using the right usb port? Are you sure the keyboard is recognized properly by PIC? The keyboard should have current consumption of 100 mA or lower.

When the keyboard is connected to USB port, first it sends "AA" to host and this way you can find out if the board is recognized. The basys 3 code from above, display over UART everything that the keyboard sends, so you could test the keyboard if it sends "AA" at the beginning.

 

Edited by Ana-Maria Balas

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now