• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 1041 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/AM3352: Unexpected GPIO values read after changing direction

Richard McAleer
Expert 1485 points

Part Number: AM3352

Tool/software: Linux

Hi

I am trying to use the sysfs GPIO interface to bitbash half duplex 9-bit SPI communications
- this requires I use the same pin as an output to send a command then switch it to an input to read the response.

Everything appears to work on the outgoing side of things
- but when I switch the PIN direction to IN, I always read 0 irrespective of the voltage applied to the pin

I am hoping that someone might be able to suggest what I could be overlooking.

The pin I am using is J15 - "mii1_rx_er"  set to mode 7 (GPIO2_2 - i.e. gpio98):

I can see via scope that the voltage changes when in output mode
- the value reported via "cat value" is correct when in output mode (matching what I see on the scope)

However once direction is changed (via echo "in" > direction) "cat value" returns 0 if the applied voltage is high or low.

I have also tried used devmem2 to change the control register (conf_mii1_rx_er - 0x44e10910) pin mux settings
- but no combination of pull up setting will cause the value reported to be "1" for a high applied voltage

Thanks for any suggestions
All the best,
Richard

  • 0
    TI__Guru**** 161600 points
    Hi Richard,

    Which SDK is this? Also what board are you using?

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Expert 1485 points
    Apologies Yordan,

    In my haste I sent my post off half empty!

    I'm working with a custom board based on the beaglebone black.
    - the SDK is a few months old, it contains kernel linux-4.4.19

    I posted a while ago about using 3wire 9bit SPI via mcspi (e2e.ti.com/.../608048)
    - and on further debugging have resorted to bit bashing from user space (as neither of approaches I have found in the kernel code work).

    The immediate problem is one of changing the direction of the GPIO pin in use for the data: I can see that the information is correct arriving at the chip (via logic analyser and scope)
    - but the value reported by the sysfs "cat value" read never changes

    Thanks for any suggestions.
    All the best,
    Richard
  • 0 in reply to Richard McAleer
    TI__Guru**** 161600 points
    Hi Richard,

    I tested this on my side. I connected gpio0_26 of my BeagleBone Black to gpio0_26 of my Beaglebone (white).
    On BBB settings are:
    echo 26 > export
    cd gpio26
    echo in > direction

    On BeagleBone White:
    echo 26 > export
    cd gpio26
    echo out > direction

    When I toggle gpio26 value on BeagleBone White (which transmits 0 or 1) the value gets reflected on BeagleBone Black (cat value returns the corresponding 0 or 1). So gpio works when configured as input (I am able to read values on gpio26).

    Can you verify that you don't have any pulls on the gpio line that hold it constantly low? Have you verified your pinmux?
    Can you test with a different GPIO pin?

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Expert 1485 points
    Hi Yordan

    it looks like I need to have the pinmux set to INPUT (with PULL disabled) for it to work

    When configured this way I am able to use it through the sysfs as an output and subsequently read it after I have switched direction to "IN".

    With the internal pulls enabled it will read all 0 or all 1 (depending on the pull direction).

    What confused me earlier is that it appears I cannot dynamically change the pinmux settings?
    I had expected devmem2 to allow me to poke the values in to the config register location (given by the trm as 0x44e10910)
    - however if I write a "new" value via devmem2 it confirms as having been written
    - but it does not appear to make any difference.

    Noticeably if I try and read the same register via "omapconf read 0x44e10910" I can see that it has not changed.
    It also appears that writing this register via omapconf fails.

    Is there a way I can access these registers effectively from userspace?

    Thanks for the help.
    All the best,
    Richard
  • 0 in reply to Richard McAleer
    TI__Guru**** 161600 points

    Hi Richard,

    Your observations are correct. The padconf address space in control module seem to be locked & you cannot set them from user space.

    Best Regards,
    Yordan