Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Kyungguk Bok wrote:

hello.

I am having a problem controlling GPIO with MityDSP-L138F through DSP and FPGA EMIF communication, so I am leaving a question.

FPGA source

constant CORE_BASE_MODULE: integer := 0;
constant CORE_TS_MODULE : integer := 5;
constant CORE_I2C_MODULE : integer := 2;
constant CORE_LCD_MODULE : integer := 3;
constant CORE_DVI_MODULE : integer := 4;
constant CORE_GPIO_MODULE : integer := 1;
constant CORE_PWM_MODULE : integer := 6;

constant CORE_GPIO_IRQ_LEVEL : integer := 1; --DSP: 1, ARM: 0
constant CORE_GPIO_IRQ_VECTOR : integer := 1;

gpio1 : gpio
generic map (
NUM_BANKS => 1,
NUM_IO_PER_BANK => 2
)
Port Map (
clk => ema_clk,
i_ABus => addr_r,
i_DBus => edi_r,
o_DBus => edo_arm(CORE_GPIO_MODULE),--edo_dsp(CORE_GPIO_MODULE),
i_wr_en => wr_r,
i_rd_en => rd_r,
i_cs => arm_cs5_r(CORE_GPIO_MODULE),--dsp_cs4_r(CORE_GPIO_MODULE),
o_irq => irq_map(CORE_GPIO_IRQ_LEVEL)(CORE_GPIO_IRQ_VECTOR);
i_ilevel => conv_std_logic_vector(CORE_GPIO_IRQ_LEVEL, 2);
i_ivector => conv_std_logic_vector(CORE_GPIO_IRQ_VECTOR, 4);
i_io => "00",
t_io => open,
o_io => o_diode,--s_diode,--o_diode,
i_initdir => "11",
i_initoutval => "00"
);

DSP source

int main() {
tcDspFirmware::set_firmware_base((void*)FPGA_BASE_ADDR);

MityDSP::tcDspFpgaGpio* mpGpio;
mpGpio = new tcDspFpgaGpio((void*)0x66000080);

mpGpio->SetPinDirection(0,0,true,0);
mpGpio->SetPinDirection(0,1,true,0);

mpGpio->SetPinValue(0,0,1);
mpGpio->SetPinValue(0,1,1);

return 0;
}

Is there anything strange about the above source?
Measured with a chipscope, there is no change.
(Attach photos.)

Is it true that the .out file was loaded in the u-boot environment as shown below, and the .out file was executed properly?
(I tried saving it to Nand flash and loading it, but the result is the same.)

Aside from this, FPGA GPIO control through fpga_ctrl.ko and fpga_gpio.ko on ARM works well.

Okay, so that should mean your fpga code is fine. Note its a good idea to make sure the fpga_gpio.ko kernel module isn't loaded if you are trying to control it from the DSP. They could fight each other.

Note your u-boot log shows the GPIO core is loaded at 0x66000280. Not 0x66000080

Thank you for answer.

I modified the part you mentioned and changed it to 0x66000080, but it still doesn't work.

today
https://support.criticallink.com/redmine/projects/arm9-platforms/wiki/DSP_Quick_Start
I've tried loading it all, but the .out file is loaded but doesn't seem to work.

Is there anything else I need to do to get it to work?

p.s By changing the HelloDSP example in a Linux environment, I was able to control the FPGA's GPIO.
By executing the command below, we were able to confirm that the .out file was executed and the FPGA's GPIO was controlled.
clipboard-202403060949-yen2s.png

Alright, let's simplify. The base module's register 0 contains some version info. You can read it 4 times in a row and then it will start repeating. For example on my board:

root@mityomapl138:~# memtool 0x66000000 1
Reading 0x1 count starting at address 0x66000000

0x66000000:  00000000   <-------
root@mityomapl138:~# memtool 0x66000000 1
Reading 0x1 count starting at address 0x66000000

0x66000000:  00004A11   <-------
root@mityomapl138:~# memtool 0x66000000 1
Reading 0x1 count starting at address 0x66000000

0x66000000:  0000891B   <-------
root@mityomapl138:~# memtool 0x66000000 1
Reading 0x1 count starting at address 0x66000000

0x66000000:  0000C000   <-------
root@mityomapl138:~# memtool 0x66000000 1
Reading 0x1 count starting at address 0x66000000

0x66000000:  00000000   <-------

If you can read this register from the DSP and get the four different values then you will at least know your talking to the FPGA correctly.