• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 256 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.

OMAP Pin Unexpectedly High-Z

Chris Read
Genius 3345 points
Other Parts Discussed in Thread: TXS0104E

I'm seeing what appears to be an OMAP-3530 pin (specifically mcspi1_simo) that is configured as an output GPIO (PINMUX value 0x0204) and is outputting a low value unexpectedly shift to high-Z.  I have observed this in two cases:

1.  In OFF mode, and in both the case with off-output-low enabled and with off-mode disabled it goes high-Z.

2.  With OFF mode enabled (/debug/pm_debug/enable_off_mode set to 1) and the pin outputting a 0, it periodically switches to high-Z for about 4ms every 5 seconds.

Any suggestions as to why this might be happening?

Thanks,

Chris

  • 0
    TI__Genius 16690 points

    Hi Chris,

    I can't find any known issue for this. From your pad config setting (0x0204), are you using the pin as gpio_172 in active mode and trying to make the status of the pin to output low by the OFF mode pad configuration in the OFF mode ? Is it possible to set the pin to output low in active mode before going to the OFF mode and keep the status during the OFF w/o using the OFF mode pad configuration ? Do you see any issue by doing this on your system ?

     

  • 0 in reply to kshin
    Genius 3345 points

    I have tried 0x0204, 0x030c, 0x021c, 0x0004, but all with the same result.  gpio_173 (sorry I had the label wrong, it was mcspi1_somi) still goes high-Z in sys-off-mode and for 4 ms every 5 seconds.  It may be that there is something in the OS (Linux PSP 3.0.1.6) that's doing it, but I don't have a good way to read the pinmux register when the system is in off mode.  I also haven't been able to detect the pinmux register changing every 5 seconds.  When I put something in to try to find out if the register is changing, the event doesn't occur.

    (The actual configuration has gpio_173 going to a TXS0104E level converter A side at 1.8V with the OE line asserted, and the output going to CMOS gate inputs.  What we see is the gpio_173 holding the line low, then sometimes it starts floating high--rising in a characteristic RC asymptotic curve, and after about 500ns it's at .8V, at which point the pullup transistor in the TXS0104E appears to turn on, and it settles at 1.4V, apparently because there is nothing driving the B side of the TXS0104E.)

    Is there something besides the mcspi1_somi's PADCONF register that affects its pad configuration?

    Thanks,

    Chris

     

  • 0 in reply to Chris Read
    TI__Genius 16690 points

    Since you are using the OFF mode, it might be related to the pad configuration save mechanism described in 7.4.4.4.1 in the TRM. Do you know if software run the process after the value was changed. You may also want to check saved pad configuration values in WKUP power domain memory (physical addresses 0x4800 2600 to 0x4800 29FC) to see the value for the register is what's expected just before going to the OFF mode.

  • 0 in reply to kshin
    Genius 3345 points

    The Linux OS is using the pad configuration save mechanism, and it is definitely being run after I change the padconf value.

    I don't know the format of the saved registers in the WKUP power domain memory, but I'm not sure that is relevant, as the saved values would be used upon resuming, but the problem I see with OFF mode is during OFF mode rather than upon a resume after OFF mode.  The PADCONF register does get the right value back, it just doesn't seem to have the right value during OFF mode.  Any other suggestions?

    Thanks,

    Chris

  • 0 in reply to Chris Read
    Genius 3345 points

    OK.  I have found in the Linux kernel (source file arch/arm/plat-omap/gpio.c) that the OS attempts to follow the "Recommended option" workaround to errata 3.1.1.160.  So the OS was manipulating the PADCONF registers behind my back.  However, it wasn't following procedure exactly, and that was causing some problems when suspending to memory (echo "mem" > /sys/power/state).  By altering the code to follow the instructions more precisely (i.e. not changing the GPIO direction or switch to safe-mode if the output was low), I was able to get GPIOs that were supposed to stay low in OFF mode to stay low when doing the suspend to RAM.  Yeah!!!   However, when not suspended to RAM, and having OFF mode enabled, the pin seems to go high-Z again intermittently--probably every time it toggles to OFF mode.  I can see that the code that transitions the PADCONF registers is running with each transition to OFF mode, but it goes to high-Z mode.

    Any suggestions?

    Thanks,

    Chris