• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 103 subscribers
  • Views 2276 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

PRU I/O pins during power up

Bob Koen
Intellectual 445 points
Other Parts Discussed in Thread: AM3359

I am using the PRU1 to control I/O pin pr1_pru1_pru_r30[8] as an output.  I have configured the device tree to set this pin as output, pulldown, mode 5 in both running and sleep modes.

i.e 0x0e0 (PIN_OUTPUT_PULLDOWN | MUX_MODE5)

What I observe is that while the am3359 boots the output pin goes high for about 5 seconds.  This wreaks havoc on the external equipment that I am trying to control during this time.

If I configure the pin as MUX_MODE7 (making it a GPIO pin) then this doesn't happen and the pin stays low during boot.  But then the  PRU does not have control of the pin.

I thought that I read somewhere that there is a way for the ARM to hand off control of a GPIO to the PRU at run time.  Maybe I am just imagining that I read that because I can't find any reference to it now.

My question:

- is there a way to leave the pin as MUX_MODE5 but not have it go high during boot?  My hardware already has an external weak pulldown resistor.

- If not, is there a way to switch control of the pin from the ARM to the PRU in application code running in the ARM?

  • 0
    TI__Guru**** 393215 points

    Hi Bob,

    What probably happens is that the pr1_pru1_pru_r30_8 register bit is not cleared initially. My suggestion is to keep the pin pinmuxed as GPIO until the PRU software is loaded and pr1_pru1_pru_r30_8 and switch the pinmux to PRU function after that. Each of the PRUs can access the rest of the device memory (including memory mapped peripheral and configuration registers) using the global memory space addresses, so you should be able to write to the pinmux register from the PRU program.

  • 0 in reply to Biser Gatchev-XID
    Intellectual 445 points

    Hi Biser,

    Thanks. You confirmed what I was thinking needed to be done but didn't tell me how to do it.  After much searching through the TRM I finally found that the pinmux is actually called the control module and section 9.3.51 of the TRM tells me how to configure the pinmux to mode 5 so that the PRU can control the pin in question.

    Unfortunately though it isn't working properly.  I worked out that the control module is at 0x44e10000 and the offset to the register that controls gpio pin 2-22 is 0x8e0. Using devmem2 I can read that address and see that the register contains 0x7 just as expected.  But if I use devmem2 to change the value in the register to 0x5 it does not change.  Devmem2 writes 0x5 and reads the value back from the register as 0x7.

    I wrote code in my user land driver to mmap this section of memory and then read, modify, write address 0x44e108e0 and got the same results.  It stays at the value configured by the device tree regardless of what I set it to afterward.

    What could be wrong?  I can't find any mention of an overall control register that might need an enable bit set before being able to modify the mode of a pin.  Is the 3.12 Linux kernel somehow preventing me from changing the mode for the pin?

    Your help is appreciated.

    Bob

  • 0 in reply to Bob Koen
    TI__Guru**** 393215 points

    I see that you have opened another thread on this too. I cannot think of any reason why devmem2 should not work. Can you post the console printout?

  • 0 in reply to Biser Gatchev-XID
    Intellectual 445 points

    Here is the console output...

    devmem2 0x44e108e0
    /dev/mem opened.
    Memory mapped at address 0xb6f79000.
    Value at address 0x44E108E0 (0xb6f798e0): 0x7

    devmem2 0x44e108e0 w 5
    /dev/mem opened.
    Memory mapped at address 0xb6fb4000.
    Value at address 0x44E108E0 (0xb6fb48e0): 0x7
    Written 0x5; readback 0x7

    I should mention that this is kernel 3.12  with a Debian filesystem.

    Sorry about posting again.  I was hoping that  if I posted the question in a different way that was more specific to the problem that I am now facing that I might get a resolution.  This issue is now holding up the first production build of the product so there is a lot of pressure to get it resolved.

    Bob

  • 0 in reply to Bob Koen
    Intellectual 445 points
    There are some pin control driver functions exposed at /sys/kernel/debug/pinctrl/44e10800.pinmux but I can't find any documentation on how to use them. Is there some function here that I can use to change the state of the pinmux at 44e108e0?
  • 0 in reply to Bob Koen
    TI__Guru**** 393215 points

    Bob,

    I have forwarded this to the SW team.

  • 0 in reply to Bob Koen
    Intellectual 520 points
    I also had the same problem and did not succeed in changing the pinmux during linux kernel runtime.
    It could be related to this note at chapter 9.1 in the TRM:
    "Note: For writing to the control module registers, the MPU will need to be in privileged mode of operation
    and writes will not work from user mode."
    (pinmux is a part of the control module)
    During bootstrap the MPU seems to be in priviledged mode because writes work at this stage.
    Is it possible that the devmem access in the kernel does not run in priviledged mode?
  • 0 in reply to Biser Gatchev-XID
    TI__Guru**** 161600 points
    Hi Bob,

    I've answered in the other thread you opened for this issue: e2e.ti.com/.../1524621

    Best Regards,
    Yordan
  • 0 in reply to Thomas Langhammer
    Intellectual 445 points
    Thanks Thomas, your answer pointed me in the right direction.

    Devmem2 does not run in kernel space. It mmaps memory (or memory mapped registers) into user space. That's why this register remained unmodifiable.

    In the end we wrote a kernel driver that changes the one register that we are interested in to the proper value. There must be a more elegant solution to this problem than that, but we never found it.

    Thanks for your help.