• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 99 subscribers
  • Views 441 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.

TMS320C6748: GP6[15] always reading 0 on IN_DATA register

Chris Widdis
Prodigy 100 points
Part Number: TMS320C6748


This pin is always reading 0, whether there is 0V or 3.3V on the pin or not, including when it is configured as an output and being driven high. When configured as an output, verified that the test point did toggle. When configured as an input, measured at the same test point when it was 0V and 3.3V, with the IN_DATA value not changing between states.. I have tried this on 2 boards with the same result. We have 15 other pins configured as inputs on our board design that have not experienced this problem, and I am quite confident in the register settings (PINMUX and GPIO), though they are included below for edification. Perhaps there is another register setting that needs to be configured for this specific pin?

I am not sure if there is something wrong with the DSP part, possibly an issue with this specific pin perhaps, or if there is a possible external schematic design problem that could cause the input to read as a 0 when a volt meter reads 3.3V. I have asked our electronics designer to have a look, but so far he hasn't been able to find anything.

Here are the register values:

Configured as an input, measuring 3.3V at the test point

PINMUX13: 0x88888888
DIR67: 0x001e8002
IN_DATA67: 0x000e0008
OUT_DATA67:0x38000008

Configured as an output, measuring 0V at the test point

PINMUX13: 0x88888888
DIR67: 0x001e0002
IN_DATA67: 0x000e0008
OUT_DATA67: 0x38000008

Configured as an output, measuring 3.3V at the test point

PINMUX13: 0x88888888
DIR67: 0x001e0002
IN_DATA67: 0x000e0008
OUT_DATA67: 0x38008008

I used a spare GPIO pin (GP3[12]) to verify that IN_DATA does toggle when the pin is configured as an output with different values driving it. 

  • 0
    TI__Guru**** 161600 points

    Hi,

    Is this TMS320C6748 LCDK or a custom board?

    Best Regards,
    Yordan

  • 0 in reply to Yordan Kovachev
    Prodigy 100 points

    It is a custom board based on the LCDK.

  • 0 in reply to Chris Widdis
    TI__Guru**** 161600 points

    Have you checked your schematics for some external pull resistors mistakenly connected the device path? This is my main concern about your problem.
    Other thing I could think of is to check the pinmux registers if there are internal pull-down resistors that may be active by default and you need to disable them.

    Best Regards,
    Yordan

  • 0 in reply to Yordan Kovachev
    Prodigy 100 points

    Sorry for the long delay in responding.

    I used an earlier board design where pin 6[15] is routed only to a test point. Same results. Verified that the pull-up / pull-down are not enabled, though I don't think that it would affect what I am seeing, especially where I can set the pin as an output and measure it with a meter to see it toggling states when programmed to do so.

    Ran a new test where I connected a different GPIO pin to the test point of pin 6[15] to create a loopback setup. I was able to configure pin 6[15] as an output, toggle between high and low, and see the result on the other pin. Switched roles, and pin 6[15] still always read low.

    Looking through spruh79C, I see in the HPI section that there are GPIO registers that enable / disable and control GPIO on the HPI pins. Reading the memory addresses for those registers does not appear to work - the values read keep changing. The BIOS PSP 03_00_01_00 and debug mode in CCS do not define those registers at all, so perhaps they aren't valid? We are using 6 other HPI pins as GPIO without this problem, though only as outputs so the problem we are seeing here would not be an issue.

    Is there something special about the HPI GPIO pins (specifically pin 6[15], UHPI_HAS) that needs to be done to use them as inputs?

  • 0 in reply to Chris Widdis
    Prodigy 100 points

    Also note that the HPIENA bit in CFGCHIP1 is set to 0.

  • 0 in reply to Chris Widdis
    TI__Guru**** 161600 points

    Hi,

    Is there something special about the HPI GPIO pins (specifically pin 6[15], UHPI_HAS) that needs to be done to use them as inputs?

    There shouldn't be anything special here, I wasn't able to find anything in the Errata as well.

    However, GP6[15] is muxed with the RESETOUT, which is part of the device reset sequences (POR, WARM RESET, etc..), take a look at Section 6.4 Reset in the Datasheet. Can you verify resets are functioning properly during device power up? Is RESETOUT released?

    Best Regards,
    Yordan