This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3356: Direct access to SPI from PRU (no bitbanging)

Part Number: AM3356

Hello everyone,

I've written a simple PRU program that handles the McSPI1 module available on the AM3356 SoC, acting as an SPI slave device.
I started from the mcspiFlash.c example available in the AM335X StarterWare package (v 02.00.01.01) and changed the configuration to enable slave mode.

In the current verison of my program I'm just polling the MCSPI_IRQSTATUS register to detect RX_FULL/RX_OVERFLOW/TX_EMPTY interrupts that I enabled by properly setting the MCSPI_IRQENABLE register. In this way, I do not need to configure the PRU Interrupt Controller.

My program is actually working well when executed from Code Composer Studio (with pinmuxing performed in a GEL initialization script), however I'm not able to make it work when loaded by the remoteproc driver running under Linux 5.10. To simplify tests, I've reduced my PRU slave program to an infinite loop that continuously load the MCSPI_TX register with 0xFF and I'm monitoring the MISO line with an oscilloscope. When the elf file is loaded via the Linux remoteproc driver, I cannot see any activity on the MISO line.

Please note that I've configured neither INTC nor the resource_table, since I'm not using both interrupts from the ARM core and the RPMsg mechanism (I'm using shared memory to exchange data with the ARM core).

The remoteproc driver tells me that the firmware is correctly loaded and running:

# echo "start" > /sys/class/remoteproc/remoteproc1/state 
[   31.089553] remoteproc remoteproc1: powering up 4a334000.pru
[   31.122632] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, size 79244
[   31.139047] remoteproc remoteproc1: remote processor 4a334000.pru is now up
# cat /sys/class/remoteproc/remoteproc1/state
running
#

In the DTS file of my board I configured pin-muxing as follows:

&am33xx_pinmux {
    spi1_pins: spi1_pins {
        pinctrl-single,pins = <
            AM33XX_PADCONF(AM335X_PIN_MCASP0_ACLKX, PIN_INPUT, MUX_MODE3)    /* (A13) (0x990) mcasp0_aclkx.spi1_sclk */
            AM33XX_PADCONF(AM335X_PIN_MCASP0_FSX, PIN_OUTPUT, MUX_MODE3)     /* (B13) (0x994) mcasp0_fsx.spi1_d0 */
            AM33XX_PADCONF(AM335X_PIN_MCASP0_AXR0, PIN_INPUT, MUX_MODE3)     /* (D12) (0x998) mcasp0_axr0.spi1_d1 */
            AM33XX_PADCONF(AM335X_PIN_MCASP0_AHCLKR, PIN_INPUT, MUX_MODE7)   /* (C12) (0x99c) mcasp0_ahclkr.spi1_cs0 */
        >;
    };
};

&pruss_tm {
    status = "okay";
};

&pruss {
    pinctrl-names = "default";
    pinctrl-0 = <&spi1_pins>;
};

and disabled the &spi1 and &mcasp0 nodes, to prevent Linux from taking control of the bus.

Do you have any idea on why Linux running on main CPU is preventing the PRU code from interacting with the McSPI module?
How can I debug PRU code when the elf file is loaded and started by remoteproc?

Some final notes:

Thanks in advance for your valuable help!

Best regards,

OneLoop