P8_45 as pruout. Isssue?

[HurthLF4]

Hi,

for an application I need 14 PRU pins (OUT) for control 7 stepper axis. I tested all pins and all works except P8_45 (0xA0). Is this a known issue?

In the attachments there are the files I tried and checked the outputs with an oscilloscope. For Pin P8_45 I get an output (frequency ~ 100kHz) as soon as the hal_pru_generic driver is loaded (even there should no output).

What I did?

1. flash the current machinekit image to BBB (Rev C)

(uname -a Linux beaglebone 4.19.106-bone-rt-r49 #1stretch PREEMPT RT Wed Mar 11 10:50:28 UTC 2020 armv7l GNU/Linux) i did it with version bone-debian-8.7-machinekit-armhf-2017-02-12-4gb.img.xz as well, no luck :(

2. change uEnv.txt settings:

#disable_uboot_overlay_emmc=1

disable_uboot_overlay_video=1

disable_uboot_overlay_audio=1

disable_uboot_overlay_wireless=1

disable_uboot_overlay_adc=1

enable_uboot_cape_universal=1

3. pinmux the pins with config-pin -f pinout.bbio (the file in the attachment)

4. start the application with ./run.py (file in the attachment)

5. check the output of the current pin

5.1 (setp [PRUCONF](DRIVER).pwmgen.00.out.00.pin       160)

5.2. switch setp [PRUCONF](DRIVER).pwmgen.00.out.00.enable    1 to 0 -> no change of the output (the issue)

6. do step 5 for all other PRU1 pins (all works except pin P8_45 (0xA0)

Is this a known issue for Pin P8_45?

Can someone help me to fix this issue? For example test the attached files to reproduce the issue?!

Best regards,

David

[HurthLF4]

The missing attachments (does only work for me if the files are in archiv)

[HurthLF4]

Ok, I think I found the answer:

The PRU task period is set using the pru_period= parameter when loading
the module (default is 10,000 nS or 10 uS if not specified). If you
want to reduce this value, make sure you leave enough overhead for the
worst-case timing path through the PRU code. You can monitor the PRU
active and idle time using the pru_busy_pin (defaults to enabled on PRU
direct output 0). The PRU busy pin *MUST* be a PRU direct I/O, and you
have to setup pin muxing to send the PRU bit to the I/O pin. By default
the LCD/HDMI signals is using the PRU I/O bit 0, so you either need to
move this signal to another pin, disable (or override) the HDMI pin
multiplexing for PRU I/O 0, or just shorten the PRU task period and hope
for the best (not recommended).

--
Charles Steinkuehler

(source: https://emc-users.narkive.com/z4IjLdcX/linear-delta-kinematics-stepper-setup-bbb-bebopr-bridge)