PRU GPIO and voltage levels

GoogleGroups
1

So, I have one of the PRU’s toggling a GPIO output to create a ~50MHz clock. On the 'scope I can see the voltage of the signal is ~0.8v not 3.3 when it’s running more slowly.

This is toggling pin P8:11 (GPIO1_13) by the way, and I’m not sure if there’s any L/C on-board that is slowing it down. I’ve set up /lib/firmware/BB-BONE-PRU-00A0.dts to look like:

/*

  • pru dts file BB-BONE-PRU-00A0.dts

*/

/dts-v1/;

/plugin/;

/ {

compatible = “ti,beaglebone”, “ti,beaglebone-black”;

/* identification */

part-number = “BB-BONE-PRU”;

version = “00A0”;

exclusive-use =

“P8.13”;

fragment@0 {

target = <&am33xx_pinmux>;

overlay {

mygpio: pinmux_mygpio{

pinctrl-single,pins = <

0x34 0x0E

;

};

};

};

fragment@1 {

target = <&ocp>;

overlay {

test_helper: helper {

compatible = “bone-pinmux-helper”;

pinctrl-names = “default”;

pinctrl-0 = <&mygpio>;

status = “okay”;

};

};

};

fragment@2{

target = <&pruss>;

overlay {

status = “okay”;

};

};

};

… where I tried to set the slew-rate to ‘fast’, disable pull-downs, and set mode 6 for the pin, thus letting me access the pin as r30:15

Is there anything I can do to increase the voltage of the output signal ? Am I stuck with it ? Or is it an artifact of the pin I happened to choose ?

Cheers
Simon

2

The pin should be 3.3V if it is connected correctly inside the processor… Is it connected to anything externally?

Gerald

3

``Hi cowboy!

I confirm, GPIO high is 3.3V. Unconnected pins (input pins without resistor) have about 0.8V.

Why don’t you use the PWM devices for that task?

Anyway, P8_11 isn’t connected to the PRUSS. This pin only works in GPIO mode (mode 7) and I’m not sure if you can reach 50MHz that way.

The faster way is to use a PRU register pin and for that you have to choose another pin (ie. P8_15 = GPIO-1/15 = PRU-0:r30.t15).

And why are you doing the pinmuxing by the device tree overlay? Instead do it from your PRUSS code! Compile a minimal device tree overlay like

`
/*

  • pru dts file BB-BONE-PRU-00A0.dts
    */

/dts-v1/;
/plugin/;
/ {
compatible = “ti,beaglebone”, “ti,beaglebone-black”;

/* identification */
part-number = “BB-BONE-PRU”;
version = “00A0”;
exclusive-use =
“P8.15”;

fragment@0{
target = <&pruss>;
overlay {
status = “okay”;
};
};
};

`

Then add to your PRUSS code (OCP master port must be enabled)


MOV r1, 0x44E10800 // CM pinmux address
LDI r2, 0b1110 // mode 6, no resistor
SBBO r2, r1, 0x3C, 1 // set pinmuxing @ball 15 (= GPIO-1/15)


That’s all. You’ll have all your code in single source and you’re much faster in doing any testing.

Good luck!

4

Slightly off topic from original question, however I cannot help but asking this question;

“Can I pinmux in PRU?” The TRM says I have to be in privileged mode to write pinmux register.

5

You need to be in priviged mode to switch on the PRUSS (ie echo PRUSSDRV > /sys/devices/bone_capemgr.9/slots).

Once the PRUSS is running, there’s no kernel software between the PRU and the pinmux registers. So the answer is yes, the PRU can do pinmuxing in privileged or unprivileged user mode.

Test the examples in libpruio to see this happen on your system

  • button configures an GPIO input pin with high resistor
  • stepper configures four output pins
  • sos unlocks the user LED3 to control this GPIO pin
6

@Cowboy

You can reach 100 MHz to toggle a GPIO pin in open loop control. This is as fast as the PWM devices. (When you need closed loop control it slows down a lot due to the latency on the OCP port.)

7

Thank you for your answer; I’ve used my own kernel module for pinmuxing, now, instead, I have another option for this task.