cannot set P9.42 as INPUT MODE6 0x26

malkowki · October 25, 2016, 2:48pm

Dear all,

I have loaded a PRU device tree as follow on Beagle bone black revC

`
Linux version 4.1.21-bone-rt-r20
Distributor ID: Debian
Description: Debian GNU/Linux 8.5 (jessie)
Release: 8.5
Codename: jessie

`

`
/*

This program configure the PRU PINS.
There are all configured in a default state, you can change them at all moment,
you just need to exchange 0x05(OUT MODE) to 0x26(IN MODE) and vice versa in the pinctrl-single part
FAST SLEW RATE | RECEIVER DISABLE | PULLDOWN | ENABLE PULLUP/DOWN | MODE 5
0 | 0 | 0 | 0 | 5= 101 =0x00000101=0x05
FAST SLEW RATE | RECEIVER ENABLE | PULLDOWN | ENABLE PULLUP/DOWN | MODE 6
0 | 1 | 0 | 0 | 6= 110 =0x00100110=0x26
In addition, the Pins P8_11, P8_12, P8_15, P8_16, P9_24, P9_26, P9_27 can also be used, however, it’s not in the
default configuration. So to used them, you have to disable furst there current functionality,
and then add them in this file.
Be careful :
P9_24, P9_26, P8_15, P8_16, can only be allocated in input mode,
P8_11, P8_12 , can only be allocated in output mode but this time in mode 6.
*/

/dts-v1/;
/plugin/;

/ {
compatible = “ti,beaglebone”, “ti,beaglebone-black”, “ti,beaglebone-green”;

/* identification */
part-number = “BB-PRU-CONFIG”;
version = “00A0”;

/* state the resources this cape uses /
exclusive-use =
/ the pin header P8 uses */

“P8.27”, /* PRU 1 r3*_8 default IN /
“P8.28”, / PRU 1 r3*_10 default IN /
“P8.29”, / PRU 1 r3*_9 default IN */

“P8.39”, /* PRU 1 r3*_6 default OUT /
“P8.40”, / PRU 1 r3*_7 default OUT /
“P8.41”, / PRU 1 r3*_4 default OUT /
“P8.42”, / PRU 1 r3*_5 default OUT /
“P8.43”, / PRU 1 r3*_2 default OUT /
“P8.44”, / PRU 1 r3*_3 default OUT /
“P8.45”, / PRU 1 r3*_0 default OUT /
“P8.46”, / PRU 1 r3*_1 default OUT */

/* the pin header P9 uses */

“P9.27”, /* PRU 0 r3*_5 default IN */

“P9.28”, /* PRU 0 r3*_3 default IN */

“P9.29”, /* PRU 0 r3*_1 default OUT /
“P9.30”, / PRU 0 r3*_2 default OUT /
“P9.31”, / PRU 0 r3*_0 default OUT */

“P9.41”, /(mode B) PRU 0 r3_6 default IN /
“P9.42”; /(mode B) PRU 0 r3*_4 default IN */

fragment@0 {
target = <&am33xx_pinmux>;
overlay {

config_pins: pinmux_config_pins{
pinctrl-single,pins = <
/* The pin header P8 uses and PRU 1 part */

/* Input part */
0x0e0 0x26 // P8_27 pr1_pru1_pru_r31_8, MODE6 | INPUT | PRU 00100110=0x26
0x0e8 0x26 // P8_28 pr1_pru1_pru_r31_10,MODE6 | INPUT | PRU 00100110=0x26
0x0e4 0x26 // P8_29 pr1_pru1_pru_r31_9, MODE6 | INPUT | PRU 00100110=0x26

/* Output part */
0x0b8 0x05 // P8_39 pr1_pru1_pru_r30_6, MODE5 | OUTPUT | PRU 00000101=0x05
0x0bc 0x05 // P8_40 pr1_pru1_pru_r30_7, MODE5 | OUTPUT | PRU 00000101=0x05
0x0b0 0x05 // P8_41 pr1_pru1_pru_r30_4, MODE5 | OUTPUT | PRU 00000101=0x05
0x0b4 0x05 // P8_42 pr1_pru1_pru_r30_5, MODE5 | OUTPUT | PRU 00000101=0x05
0x0a8 0x05 // P8_43 pr1_pru1_pru_r30_2, MODE5 | OUTPUT | PRU 00000101=0x05

/* The pin header P9 uses and PRU 0 part */

/* Input part */
0x1a4 0x26 // P9_27 pr1_pru0_pru_r31_5, MODE6 | INPUT | PRU 00100110=0x26

/* Output part */
0x194 0x05 // P9_29 pr1_pru0_pru_r30_1, MODE5 | OUTPUT | PRU 00001101=0x05
0x198 0x05 // P9_30 pr1_pru0_pru_r30_2, MODE5 | OUTPUT | PRU 00001101=0x05
0x190 0x05 // P9_31 pr1_pru0_pru_r30_0, MODE5 | OUTPUT | PRU 00001101=0x05

;
};

};
};

//Allowed us to have the differents uio
fragment@1{
target = <&pruss>;
overlay{
status = “okay”;
pinctrl-names = “default”;
};
};

//Make the uio working
fragment@2

target = <&ocp>;
overlay {
#address-cells = <1>;
#size-cells = <1>;

gpio_keys {
compatible = “gpio-keys”;
pinctrl-names = “default”;
pinctrl-0 = <&config_pins>;
#address-cells = <1>;
#size-cells = <0>;
};

};
};

};

`
the DTO is loaded correctly, but when I checked the PINS configuration it shows this:

cat $PINS| grep '89\| 103\|100' pin 36 (44e10890.0) 00000037 pinctrl-single pin 37 (44e10894.0) 00000037 pinctrl-single pin 38 (44e10898.0) 00000037 pinctrl-single pin 39 (44e1089c.0) 00000037 pinctrl-single pin 89 (44e10964.0) 00000027 pinctrl-single ????? pin 103 (44e1099c.0) 00000026 pinctrl-single

Why pin 89 is set as 0x27 (GPIO MODE) instead of 0x1a0 0x26 // P9_42B pr1_pru0_pru_r31_4, MODE6 | INPUT | PRU 00100110=0x26??

Any Idea what could be the reason???

Charles_Steinkuehler · October 25, 2016, 3:30pm

Because you are not setting the pinmux at 0x964 (P9_42), just the one
at 0x9a0 (P9_42B).

The pinmux at 0x9a0 should be set for PRU in, and the pinmux at 0x964
should be set for GPIO input to avoid potentially conflicting with
whatever is driving the signal.

malkowki · October 25, 2016, 4:01pm

Hello Charles,

Thanks for this remark, I have changed the dts file now it is ok.

I want to force 3.3V to the PIN9.42 and check in the memory register that the value is “1”, do you know how I can check this?

malkowki · October 25, 2016, 4:02pm

Hello Charles,

Thanks for this remark, I have changed the dts file now it is ok.

I want to force 3.3V to the PIN9.42 and check in the memory register that the value is “1”, do you know how I can check this?

Charles_Steinkuehler · October 25, 2016, 4:34pm

Since you are not claiming the pin in your device-tree overlay (you
should, and force it to be an input), you ought to be able to simply
export the GPIO via the kernel and set it to output a '1' like any
other GPIO pin.

malkowki · October 25, 2016, 6:12pm

In fact I want to check the PRU memory register when the pin is set as input and forced to 3.3V. I know that from user space we use sysfs to export the pin. I have some doubt if it the same mechanism for the PRU GPIO?

Charles_Steinkuehler · October 25, 2016, 6:18pm

Leave the PRU input (P9.42B) alone. Export the other pin (P9.42) as
GPIO and set it to drive high. Since the pins are wired together on
the BBB, the PRU should see the input as '1'.

Make sure you switch P9.42 back to input before hooking it to whatever
signal source you're planning on using.