• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 2 answers
  • Subscribers 99 subscribers
  • Views 1133 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Linux/AM5728: PRU pinmux issue

Patrick Oetken
Prodigy 190 points
Part Number: AM5728
Other Parts Discussed in Thread: BEAGLEBOARD-X15

Tool/software: Linux

Hello,

I need GPIO access for one PRU of the AM572x (Beagleboard X15). I'm using PROCESSOR-SDK-LINUX-RT-AM57X  05_03_00_07.

I used the Pinmux Tool to add the PRU GPI/GPO and the Pearl script to create the output for editing U-Boot. After that I edited the existing lines and added non-existing lines in mux_data.h (iodelay.txt to iodelay_cfg_array_x15_sr2_0[] and iopad.txt to core_padconf_array_essential_x15[]) .

I then recompiled U-Boot and copied the new MLO and u-boot.img to the boot partition.

I also added the content of devicetree.txt:

&dra7_pmx_core {

};

&dra7_iodelay_core {
// for linux kernel 4.4 / processor sdk 3.x
};

to am57xx-beagle-x15-revc.dts and recompiled linux-dtbs, but I think that does not effect anything. I then renamed the dtb to am57xx-beagle-x15-revc-new.dtb and added a line fdtfile=am57xx-beagle-x15-revc-new.dtb to uEnv.txt to be sure it is used (and it seems to work).

I booted Linux to let u-boot make the pinmux config and used the XDS110 and CCS to run a simple assembly programm on PR1_PRU0 to set and reset R30 for testing the pins. But I don't see any changes on the GPOs after writing to R30.

I think there is something wrong with my pinmux configuration. For my programm I assume that pin pr_1_pru0_gpo1 is position 1 << 1 in R30. 

Is there any point that I am missing?

I attached the Pinmux project and the created files.

6862.pinmux.zip

  • 0
    TI__Guru**** 161600 points

    Hi,


    Which gpio pin are you using? Make sure that this pin is NOT used by any other kernel driver or if it is not muxed as anything else in your system.


    Best Regards,
    Yordan

  • 0 in reply to Yordan Kovachev
    Prodigy 190 points

    Hello Yordan,

    these are the pins I want to mux for PRU usage with PRUSS2_PRU0_IOSET2:

    GPIO6_11
    MMC3_CMD
    EHRPWM2A
    MMC3_DAT0
    MMC3_DAT2
    MCASP2_AXR2
    MCASP7_FSX
    MCASP2_CLKX
    MCASP2_AXR3
    MMC3_DAT3
    MMC3_CLK
    MMC3_DAT1

    I already had success with a few of them, but the other ones are still not working.

    I just opened the evmAM572x_SR2.0.pinmux provided by TI platform development kit and added these pins to PRUSS2_PRU. To solve pin conflicts, I had to disable:

    GPIO6_11
    LCD VOUT
    MMC3
    MCASP7
    eHRPWM

    As I can see from the schematics these functions are not neccessary for running the board properly, are they?

    And in mux_data.h I can exchange the whole structures core_padconf_array_essential_x15[] and iodelay_cfg_array_x15_sr2_0[] with the newly created files based on evmAM572x_SR2.0.pinmux?

    Thanks a lot!

    Kind regards,

    Patrick

  • 0 in reply to Patrick Oetken
    Prodigy 190 points

    I just tried the pinmux based on evmAM572x including the changes mentioned above and it also does not work for all pins.

    Pins that are not working:

    EHRPWM2A

    MMC3_DAT0

    MMC3_DAT2

    MCASP2_AXR2

    MCASP7_FSX

    MCASP2_CLKX

    MCASP2_AXR3

    Pins that worked with at least one of my configurations:

    GPIO6_11

    MMC3_CMD

    MMC3_DAT3

    MMC3_CLK

    MMC3_DAT1

    I attached the pinmux-related files including uboot's mux_data.h.

    Kind regards,

    Patrick

    pinmux_evm_am572x.zip

  • 0 in reply to Patrick Oetken
    TI__Genius 13567 points

    Hi Patrick,

    I reviewed the mux_data.h and the pinmux file you attached. I see you have pins set up in the PRU correctly in the pin mux tool and nothing stands out in the mux_data.h file either. 

    After Linux has booted, it would be good to read back some of these pad configuration registers to make sure the intended mux mode is applied. Using the "genericFileFormatPadConf.txt" file would be a good way to find the register address and register data required for each pin to work. Are you familiar with the devmem2 command? 

    devmem2 0x4A00377C w

    This command will read back the mmc3_clk pin for example. You can try other addresses based on that generic padconf text file. 

  • 0 in reply to Ahmad_Rashed
    Prodigy 190 points

    I checked the register values using devmem2 and they all match the values listed in genericFileFormatPadConf.txt, according to that I assume u-boot does it's job correctly?

    After booting the board I measured 3.3V/high level at the working pins and the non-working pins are at 0V/low. Because of that it seems like the configured pullups for these pins are also not enabled.

  • 0 in reply to Patrick Oetken
    TI__Genius 13567 points

    Do you have any PRU binaries automatically loading when Linux boots? Something running on the PRU core may be driving the pin outputs.

  • 0 in reply to Ahmad_Rashed
    Prodigy 190 points

    It's just a bare Linux-RT SDK image with the newly built u-boot including the pinmux config, so I think there should be nothing running on the PRUs.

  • 0 in reply to Patrick Oetken
    TI__Genius 13567 points

    For the Linux SDK, depending on the board it will run a "PRU-ETH" firmware to allow the PRU ethernet ports to appear as a standard ethernet port in Linux. The Linux-RT SDK is likely configured the same.

    Use the 'ls -l" command to list firmwares in the /lib/firmware/ directory. You'll see some file names along the lines of am57xx-pruX_Y-fw. You can delete these symbolic symbols to prevent the firmware from loading. 

  • 0 in reply to Ahmad_Rashed
    Prodigy 190 points

    It was not the PRU-ETH firmware running on the PRUs, but the rpmsg echo example.

    root@am57xx-evm:/lib/firmware# ls -l
lrwxrwxrwx    1 root     root            49 Apr  6  2019 am57xx-pru1_0-fw -> /lib/firmware/pru/PRU_RPMsg_Echo_Interrupt1_0.out
lrwxrwxrwx    1 root     root            49 Apr  6  2019 am57xx-pru1_1-fw -> /lib/firmware/pru/PRU_RPMsg_Echo_Interrupt1_1.out
lrwxrwxrwx    1 root     root            49 Apr  6  2019 am57xx-pru2_0-fw -> /lib/firmware/pru/PRU_RPMsg_Echo_Interrupt2_0.out
lrwxrwxrwx    1 root     root            49 Apr  6  2019 am57xx-pru2_1-fw -> /lib/firmware/pru/PRU_RPMsg_Echo_Interrupt2_1.out

    I deleted these symbolic links, but that unfortunately does not resolve the issue. Any other hints?

  • 0 in reply to Patrick Oetken
    Prodigy 190 points

    I just switched the SD card to another Beagleboard-X15 and it works without any problems. It seems like the board / the pins are broken. Is there a way to figure out what could possibly has gone wrong?

  • 0 in reply to Patrick Oetken
    TI__Genius 13567 points

    Hi Patrick,

    It's hard to say, though it seems some kind of electronic over stress event has happened. The root cause could be many things, even something unexpected. Pins can get damaged if IO signals are driven into the processor while it's powered off. Or there could have been an ESD event. 

    Regards,
    Ahmad