• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 30 subscribers
  • Views 496 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.

TMS570LS3137: NHET1 pins 21, 23, 25 not working when configured as inputs

Joe Barrus
Prodigy 80 points
Part Number: TMS570LS3137
Other Parts Discussed in Thread: HALCOGEN

We are using the TMS570S3137.

We need to use NHET1[21],NHET1[23],NHET1[25] as GPIO inputs, but they don't read the value of the signal connected to them.

These signals are MUXed and PINMUX appears to be configured correctly.

These pins work correctly when configured as outputs but not as inputs.

I created a test project to work with the TMS570LS31x Hercules Development Kit (HDK) that demonstrates the issues, see attached.

The test project is as simple as I could get it  --  I have 4 NHET pins configured as outputs driving 4 NHET pins configured as inputs.

I added 4 jumpers to the 3137 HDK connecting the 4 outputs to the 4 inputs.

NHET1 11, 21, 23, and 25 are configured as inputs in HALCoGen, and NHET1 10, 20, 22, 24 are configured as outputs.

The red lines below represent the 4 jumpers between the pins on the HDK, J11 header, on the bottom side of the HDK PCB.

 

The attached code drives the outputs high then low and reads the input pin at each change.

One of the NHET input pins(NHET11) is included as a ‘good’ reference and works as expected, whereas NET21, 23, and 25 do NOT work.  Specifically the values read from NHET21,23 and 25 do NOT change when the output pin each is jumpered to changes.  NHET1[11] is configured the same as NHET1[21], NHET1[23] and NHET1[25], but they behave differently!

 Note that NHET 21, 23 and 25 DO work correctly when configured as outputs, but NOT as inputs.  Very weird.

NHET 21, 23 and 25 are MUXed, but PINMUX looks to be configured correctly, see attached HALCoGen file.

We would LOVE to know what we are missing to configure these NHET pins as inputs!

Thanks a bunch,

-Joe


GPIO_Test.zip

  • 0
    TI__Guru 70241 points

    Hi Joe,

    Can you please do one small testing and let me know the results.

    Just try to set a breakpoint after "gioSetBit" function for all NHET 21, 23 and 25.

    For example, for N2HET25 as below

    After setting break point after gioSetBit function now debug and verify whether the error_count is incrementing or not. It should not increment.

    What i am suspecting is that there are bidirectional buffers in between these pins.

    And these buffers have some propagation delay, so if we change the output value using gioSetBit function it will not immediately reflect at input pin and it will take some time. So just set the break points as i mentioned and verify it.

    Also i want to suggest you one more modification that, 

    As you are using N2HET1[21] on H4, N2HET1[23] on J4 and N2HET1[25] on M3 right? then don't enable the pin functionalities on the 

    V5, J3 and G19

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 80 points

    Hi Jagadish,
    Thanks for the prompt reply.
    I’m happy to see you working this issue as you have helped me solve difficult 3137 issues in the past.

    I added the breakpoints per your suggestion.
    Adding the breakpoints did NOT change the behavior, so I guess it isn’t a timing issue.

    With a lot of skepticism I deselected the NHET pins in HALCoGen PINMUX screen and to my astonishment that caused the pins to work as inputs!!
    The test program now runs with the inputs reading the same as the attached outputs and error_count = 0!!
    See below screen shots:

    1. Why does this work?
    2. Is this the suggested fix?
    3. Should I expect this to work when the other pin function modules are enabled and used, e.g. MIBSPI1 and MIBSPI3?

    Thanks a bunch!
    -Joe

  • 0 in reply to Joe Barrus
    TI__Guru 70241 points

    Hi Joe,

    Joe Barrus said:
    1. Why does this work?
    2. Is this the suggested fix?

    Yes, this is correct.

    This is because:

    In the controller few functionalities will be on multiple pins, for example

    As you can see N2HET1[21] is available on either H4 or J3, N2HET1[23] is available on either J4 or G19 and similarly N2HET1[25] will be available on either M3 or V5.

    Here H4, J4 and M3 pins are called dedicated pad functionality pins, because these pins have only one functionality. Whereas J3, G19 and V5 pins are called multiplexed functionality pins, because these pins have more than one functionality is available.

    By default, the input will be taken from dedicated functionality pins. I mean for example if i didn't enable the N2HET1[21] functionality on J3 using HALCoGen then the N2HET1[21] functionality will be taken from the H4. However, if you enable the N2HET1[21] functionality on multiplexed input in this case it is J3 then the input is taken from the multiplexed pin instead of dedicated pin. And same thing applicable for other two pins as well.

    If you consider your case previously you enabled N2HET1 functionality on multiplexed pins but whereas you are expecting to read your input from dedicated pads, that is the reason you didn't get the input.

    --
    Thanks & regards,
    Jagadish.

  • +1 in reply to jagadish gundavarapu
    Prodigy 80 points

    Hi Jagadish,

    Thanks for the detailed explanation, that makes sense now.

    Best Regards!

    -Joe