• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 97 subscribers
  • Views 362 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.

gpio_1 / sys_clkreq

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

I have a OMAP3530 based system where two GPIOs are tied together:

     GPIO_1 is tied to GPIO_70, and they are pulled up to 1.8V (VIO) via a 1kOhm resister.

When the PADCONF for both pins is set to 0x011c (input, pulled up), and both GPIO_1 and GPIO_70 are configured as inputs then the pins sit at about 1.0V, which isn't really a legal value.

If I turn GPIO_1 into an output, then it can control the signal, and GPIO_70 reads it clearly.

If, however, I have GPIO_1 as an input and GPIO_70 as an output, then GPIO_70 can't control the voltage on the line enough for.

Is there something strange with the GPIO_1 input?  Is there any other configuration that needs doing?

Thanks in advance,

Chris

  • 0
    Genius 3345 points

    I note in the OMAP3530 TRM (Rev. X) Figure 4-12 that it states that sys_clkreq can be used as a GPIO (input only) in the case where sys_boot6 is pulled down (i.e. Master Mode).

    Does this mean that it can't be used as a GPIO if sys_boot6 is pulled high at reset, even if the PADCONF configures it as a GPIO?

    Does this mean that the sys_clkreq circuitry takes over the output and makes GPIO_1 unusable as an input if sys_boot6 is pulled up (i.e. Bypass Mode)?

    Thanks,

    Chris

  • 0 in reply to Chris Read
    Genius 3345 points

    Since GPIO_1 is tied to GPIO_70 (dss_data0 pin) on our board that when the power to part of the display hardware (vdda_sdi) was being turned off that GPIO_70 hung things.  Keeping vdda_sdi on allows the GPIO_1 / GPIO_70 node to function properly.