GPIO Hardware Interrupt from Logi-bone

SeatherMarqx0

Kind of a newbie here.

I'm simply trying to have the Spartan set a GPIO to high when an SPI Slave transaction is completed.

To test the hardware trigger portion, I modified the led_blink code to output to the beaglebone GPIO_45. I may have done this wrong as VHDL is completely new to me. It also seems that this pin is used for GPMC for the logi....

GPMC_AD(13) is mapped in the ucf to P115

Test VHDL:

library IEEE;

use IEEE.STD_LOGIC_1164.ALL;

use IEEE.STD_LOGIC_UNSIGNED.ALL;

--use IEEE.NUMERIC_STD.ALL;

entity logibone_blink is

port( OSC_FPGA : in std_logic;

LED : out std_logic_vector(1 downto 0);

GPMC_AD : out std_logic_vector(15 downto 0)

);

end logibone_blink;

architecture Behavioral of logibone_blink is

-- Led counter

signal counter_output : std_logic_vector(31 downto 0);

begin

process(OSC_FPGA)

begin

if OSC_FPGA'event and OSC_FPGA = '1' then

counter_output <= counter_output + 1 ;

end if;

end process ;

LED(0) <= counter_output(24);

LED(1) <= counter_output(23);

GPMC_AD(13) <= counter_output(22);

end Behavioral;

--------------------------------------------------------------------------------------------------------------------------------------------

Have I completely butchered this or is there a better workflow I should approach?

Thanks,

-Seather

SeatherMarqx0

No reply from anyone. This could be from my poor wording.

From what I've seen so far, I need to keep the GPMC as-is in order to maintain a fast connection through wishbone but there's nothing stopping me from using the Chip Select as an interrupt from the device tree.

I'll try again and post my findings.

mjones

Hi Seather, 

Thanks for dropping in.  You are definitely taking the right approach.  Your code looks fine.  But, there may be a conflict with the GPMC IO state.  I am not sure what the state of the GPMC_AD pins are configured to by default with and without running the device tree.  If the pin is not toggling the way that you expect it is likely configured as a output which will keep the pin low even if the FPGA is toggling it. @jpiat   can let you know the specifics of the IO configuration state upon BBB booting.  I am not sure how you are you are testing the pin, but it may be toggling too fast for you test method.  counter_output(22) is toggling at 4x the rate of LED0 and 2x of LED1.  You could use a higher bit value if you want ensure a slower rate such as counter_output  bit 25 up to 31 depending on the rate you want.  Or just hard set the pin to '0' or '1' and measure with a meter.  

The best way to test this would be to use a PMOD or Arduino header pin that is ensured not to be conflicting with any other functionality.  If you are scraping for IO pins there are some wired pins that could be used.  I would need to look at the schematic.  Let me know and I can do some looking.

Cheers,

Mike

SeatherMarqx0

Great to be here.

I've modified the HDL to trigger GPMC_AD(13) to high when PB(0) is pressed and I still saw no change in the pin state.

With the new CS thought in mind, I figured I'd use the (unused?) SPI interface that is shared between the BB, Spartan and the Arduino cape (not using one).

This was checked with:

HDL:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
--use IEEE.NUMERIC_STD.ALL;

entity logibone_blink is
port( OSC_FPGA : in std_logic;
		PB: in  std_logic_vector(1 downto 0);
		LED : out std_logic_vector(1 downto 0);
		SYS_SPI_SS : out std_logic
);
end logibone_blink;

architecture Behavioral of logibone_blink is
	
	-- Led counter
	signal counter_output : std_logic_vector(31 downto 0);
	
begin
	process(OSC_FPGA)
	begin
		if OSC_FPGA'event and OSC_FPGA = '1' then
			counter_output <= counter_output + 1 ;
		end if;
	end process ;

	LED(0) <= not (PB(0));
	SYS_SPI_SS <= not (PB(0));
	LED(1) <= not (PB(1));
end Behavioral;

Linux:

echo 28 > /sys/class/gpio/export
cat /sys/class/gpio/gpio28/value //Looking for change here when pressing button.
0

This had no success but was informative. It's certain now that I have the device tree setup incorrectly and I'll reconvene here with my findings.

Thanks again,

Seather

mjones

Hi Seather,

I tested the IO toggling on the GPMC_AD pins, which did not work.  The appear to be set as outputs and high after device tree setup.  I did test the SS pin which worked fine.  

entity logibone_blink is

port( OSC_FPGA : in std_logic;

PB: in  std_logic_vector(1 downto 0);

LED : out std_logic_vector(1 downto 0);

GPMC_AD: out std_logic_vector(15 downto 0);

SYS_SPI_SS : out std_logic

);

end logibone_blink;

architecture Behavioral of logibone_blink is

-- Led counter

signal counter_output : std_logic_vector(31 downto 0);

begin

process(OSC_FPGA)

begin

if OSC_FPGA'event and OSC_FPGA = '1' then

counter_output <= counter_output + 1 ;

end if;

end process ;

LED(0) <= not (PB(0));

LED(1) <= not (PB(1));

SYS_SPI_SS <= '1' when counter_output(24) = '1' else '0';

--GPMC_AD <= x"ffff" when counter_output(24) = '1' else x"ffff";  --this is fighting with the io state of the configured GPMC pins on the BBB

end Behavioral;

Let us know how things go.  We need to get some better documentation of the pins states per the device tree setup options.  @jpiat can let you know what the current setup is based on the current logi images.  He is out of town at the moment, but will respond when he can.

Cheers,

Mike

jpiat

Hi,

If you want to use the gpmc pins as gpio you will need to modify the device tree setup. I can generate an image for you with a device tree file that setup the gpmc pins as gpios (preferably not the one that are shared with the emmc) when I get back (not before the 13th). N the device tree these pins are pulled high in the MUX settings and controlled by the gpmc controller (which might force them in a given state). When I debugged the gpmc interface, the logic analyzer showed that the gpmc pins were forced in a given state even after a transaction occured. I will be of better help when I will have my computer and logo board on hand ...

Regards,

Jonathan piat

SeatherMarqx0

I don't want to lose the precious DMA from the GPMC. My current solution is to send one of the unused PMOD pins back to a configured GPIO on the BeagleBone. I'll post my results once I get back to the board myself.

//Seather