RTOS/PROCESSOR-SDK-AM437X: Partial PR1_PRU0 pins cannot be directly input and output

Hi Zhuangbin,

When you change the pinmuxing to GPI mode, make sure to also set the RXACTIVE bit in the CTRL_CONF_GPMC_AD* register.

In your PRU firmware, are you declaring __R30 and __R31 as follows?

volatile register uint32_t __R30;

volatile register uint32_t __R31;

Regards,

Melissa

Hi,

I am sure, when testing the GPI, I had set the RXACTIVE. my program is based on the example PRU_gpioToggle from pru-software-support-package. R30 and R31 define as follow:

volatile register uint32_t __R30;
volatile register uint32_t __R31;

and ouput test code as follow:

    /* GPI Mode 0, GPO Mode 0 */
    CT_CFG.GPCFG0 = 0;
    /* Clear SYSCFG[STANDBY_INIT] to enable OCP master port */
    CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;

    __R30 = 0xFFFFFFFF;
    i = __R31;
    __R30 = 0;
   i = __R31;

I use the emulator to  step into each instruction line.

now, I have confirmed that pr1_pru0_gpi[9] read and pr1_pru0_gpo[9] write is ok, pr1_pru0_gpi[16] read is ok.

                                          pr1_pru0_gpo[10] and pr1_pru0_gpo[11] can not write. pr1_pru0_gpi[10] and pr1_pru0_gpi[11] can not read.

the arm pinmux file as follow, I hope you can confirm it in practice.

2677.am43xx_evmsk_pinmux_data.c

Hi，

Yes，I am using a custom board. E11 and C11 is connected to a high level(3.3V).

and pr1_pru0_gpo[9](F10) is ok under the same conditions.

6076.am43xx_evmsk_pinmux_data.cHi Melissa,

the GPIO1[12] and GPIO1[13] is OK.

in ARM it initialize the pinmux with attached files, and in the pru it executes the codes as follow:

/* LED port address */
#define GPIO1_BASE_ADDR 0x4804C000
#define GPIO_OE_OFFSET         0x134
#define GPIO_CLRDATAOUT_OFFSET 0x190
#define GPIO_SETDATAOUT_OFFSET 0x194   

    uint32_t led_set_addr;
    uint32_t led_clr_addr;
    uint32_t led_oe_addr;
    led_set_addr = GPIO1_BASE_ADDR + GPIO_SETDATAOUT_OFFSET;
    led_clr_addr = GPIO1_BASE_ADDR + GPIO_CLRDATAOUT_OFFSET;
    led_oe_addr = GPIO1_BASE_ADDR + GPIO_OE_OFFSET;
    /* GPI Mode 0, GPO Mode 0 */
    CT_CFG.GPCFG0 = 0;
    /* Clear SYSCFG[STANDBY_INIT] to enable OCP master port */
    CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;


    *(uint32_t*)led_clr_addr = 3<<12; //turn off
    *(uint32_t*)led_oe_addr = 0xFFFFCFFF;  // output enable
    *(uint32_t*)led_set_addr = 3<<12; //turn on

Hi,

The manual does not seem to say that __R30 can read back the GPO value, so I did not try to read it. 

I used 3.3V power supply cathode directly to the input terminal, the other input pins are all right. 

I'm 80% sure that these two pins are not available as GPIO in PRU. I hope you can confirm it in practice. 

Hi zhuangbin,

You can use the PRU_ICSS_DBG_GPREG30 register within the PRU to read back the R30 or GPO value.  Alternatively, if you're connected to CCS, then you could also use the Register window to view R30.

I am able to see both pr1_pru0_gpo[10:11] toggle on the AM437x IDK.  The IDK brings C11 and E11 to a header, so this test was done with nothing connected to the pins.

Below is a description of my test, which was implemented using the CCS debugger:

1. Powered up the AM437x IDK and connected to the CortxA9

2. Opened a memory browser to the CTRL_CONF_GPMC_AD[12:13] registers (address 0x44E10830 and 0x44E10834)

3. Programmed 0x9 into both of these registers to configure the mux mode to pr1_pru0_gpo mode

4. Connected to PRU-ICSS1 PRU0

5. Opened the CCS Register window associated with the PRU-ICSS1 PRU0 core, expanded the Core Register section in this window, and scrolled down to R30

6. Wrote 0x400 into R30, and saw GPO10 = 1, GPO11 = 0 on logic analyzer

7. Wrote 0x800 into R30, and saw GPO10 =0, GPO11 = 1 on logic analyzer

Note, the default GPCFG0 register setting is 0x0, so direct output mode is selected for this test. 

Regards,

Melissa

Hi，

My IDE can not connect the PRU directly, it must execute an initialization code in ARM before. 

But I can operate the registers and R30 like your description. but can not get the expected output.

Are you sure the CPU is same as my AM4376?

Zhuangbin,

Yes, the CPU is the same with respect to basic PRU functionality and pin out.

A few suggestions to continue debugging:

1. After writing to R30's bit 10/11, check the R30 register content either in the CCS Register window or PRU_ICSS_DBG_GPREG30 register.  Do you see the expected value stored in this register?
2. After toggling R30's bit 10/11, check that the device pinmuxing and PRU-ICSS's CFG_GPCFG0 register still read the expected value.
3. Check the voltage on the GPO10 and GPO11 pins, both after setting and clearing the R30 bits.  What voltages do you see?  
4. Disconnect everything that's connected to the GPO10 and GPO11 pins on your board.  Can you now toggle the pins with the PRU GPOs?

Also, how are checking that GPO10 and GPO11 are toggling on your board?

Regards,

Melissa

Hi zhuangbin,

3. the voltage on the GPO10 and GPO11 pins is always 0 level, whatever value I write to it.

Do you see ANY change in the voltage when you set the pin in software?   Even if it only changes by a small amount (i.e.100 mV), that could help give us an idea of what's happening on the pin.  

Regards,

Melissa

Hi Zhuangbin,

What about the power supply rails VDDSHV9 and VDDSHV10? Are they supplied from the same source?

E11 gpmc_ad12 (pr1_pru0_gpo10) is supplied by VDDSHV9 - not working
C11 gpmc_ad13 (pr1_pru0_gpo11) is supplied by VDDSHV9 - not working
F10 gpmc_csn2 (pr1_pru0_gpo9) is supplied by VDDSHV10 - working

You mentioned that pr1_pru0_gpi16 is working properly, but I do not see it configured in the pin mux output.
B11 gpmc_ad14 (pr1_pru0_gpi16) is supplied by VDDSHV9 - working

Regards,
Mark

Hi Mark,

the power supply rails VDDSHV9 should be ok, because that if setting the 16 bits data / 16 bits address non multiplexing bus, it work orderly. 

I had tested the output function of pr1_pru0_gpi16 by another pinmux file.