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

GPIO107 configuration problem

vincent chardon
Prodigy 70 points
Other Parts Discussed in Thread: DM3730

Dear sir,

I am trying to use GPIO107 as a standard GPIO.

I am able to drive as expected GPIO67. And I am trying to to the same thing with GPIO107. In Linux, initialization sequence is as follow :

  • omap_mux_init_gpio( 107, OMAP_PIN_OUTPUT);
  • gpio_request( 107, "nRST_LCDEXT"); 
  • gpio_direction_output( 107, true);
  •  gpio_set_value(107 , 1);

Then I would expect to see a high level on the GPIO. But this is not the case, in fact as soon as omap_mux_init_gpio has been called, the output seems to be in high-z.

I have also tried  the same operation by acting directly on the registers

  • Configure CONTROL_PADCONF_CAM_D7[31:16] in mode 4
  • configure relevant pin in GPIO_OE (GPIO4) as output
  • write 1 to the relevant pin of GPIO_SETDATAOUT

Then as above I would expect  the pin to go to high level but this is not the case. I have also checked that functionnal and interface clock for GPIO4 was enabled.

Has gpio107 anything special ? Is there some additional configuration to be done for gpio107 ?

 

Thanks in advance for your responses,

Regards

  • 0
    Prodigy 70 points

    High,

    I have forgotten to precise in my previous post, that I was working on an omap3, DM3730 processor. Any advice is welcome.

     

     

    Thanks for your  help

    Regards

  • 0 in reply to vincent chardon
    TI__Expert 8180 points

    Hi,

    I suspect, the pad configuration here, So can you dump the pad config register settings to cross-check?

    Thanks,

    Vaibhav

  • 0 in reply to Vaibhav Hiremath
    Prodigy 70 points

    High,

    Using omap_mux directory in debugfs I obtain following result :

    #cat cam_d8
    name: cam_d8.gpio_107 (0x48002126/0x0f6 = 0x0004), b j23, t NA
    mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE4
    signals: cam_d8 | NA | NA | NA | gpio_107 | NA | NA | safe_mode

    When I am exporting GPIO_107 (via sysfs /sys/class/gpio/gpio107), I put the gpio in output mode

    # cat direction
    out

    And I change value (echo 1 > value), and the value at the output does not change.

    With a JTAG probe I have read  CONTROL_PADCONF_CAM_D7 and its value is 0x0004010F (Confirming mode 4 has really been selected). I can also say I was monitoring the right pin as initially a pull down is enabled and when the configuration is applied the output is in high Z ( not tied to 0 by a pull down any more). I have successfully driven GPIO103  wich is in GPIO4 as well, so I don't think the problem ir related to GPIO submodule. ( i.e. GPIO4 module is enabled and clocked.)

    Since this output is a test point on our hardware no voltage have been applied to it,  I  can hardly imagine the ouput buffer being damaged. Can it be a DM3730 bug ? (I have seen nothing about it in erratasheet.)

     Thanks for your support

    Regards.

     

     

  • 0 in reply to vincent chardon
    TI__Expert 8180 points

    Everything seems ok to me, can you try enabling pulll up and pull down setting and see atleast you get high and low based on this?

    It would be very premature statement  to say that it is silicon bug, I would suspect it last.

    Thanks.

    Vaibhav