• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 418 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F28P650DK: Where exactly CLB output xbar connected to the GPIO

Alexey Zaparovanny
Prodigy 10 points
Part Number: TMS320F28P650DK
Other Parts Discussed in Thread: SYSCONFIG, C2000WARE

TRM shows following picture, however using GPIO32 with CLB5.0 output i seem to observe CLB output regardless of the state of GPyDIR bit.

GPIO output changes when change GPBGMUX1 & GPBMUX1, so clb-output-xbar is going to the multiplexor but tir-state buffer shown seem to be ignored.

In additon i seem be to unable to route TILE output CLB5.0 to any other GPIO, for example gpio 41 is not producing output (stays zero)  that i observe when i route to GPIO32 but does react to XBAR_invertOutputSignal(...) quite puzzling....

  • 0
    TI__Mastermind 23230 points

    Hi Alexy,

    When you configure GPIO32 to be an input, is the standard GPIO settings selected in the mux options?

    Could you share the code you are writing to send the CLB output to GPIO41?

    Thank you,

    Luke

  • 0 in reply to Luke Jones
    Prodigy 10 points

    Hello Luke, I was just changing GPBDIR register, i suspect that extra line that goes from the mux to GPBDIR overrides my settings ? Does not look like i can attach sysconfig to this message, but i'll try to post it as a code - it contains full configuration that i was trying to make to work.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    /**
    * These arguments were used when this file was generated. They will be automatically applied on subsequent loads
    * via the GUI or CLI. Run CLI with '--help' for additional information on how to override these arguments.
    * @cliArgs --board "/boards/LAUNCHXL_F28P65X" --context "CPU1" --product "C2000WARE@5.01.00.00"
    * @versions {"tool":"1.19.0+3426"}
    */
    /**
    * Import the modules used in this configuration.
    */
    const adc = scripting.addModule("/driverlib/adc.js", {}, false);
    const adc1 = adc.addInstance();
    const adc2 = adc.addInstance();
    const adc3 = adc.addInstance();
    const analog = scripting.addModule("/driverlib/analog.js", {}, false);
    const analog1 = analog.addInstance();
    const asysctl = scripting.addModule("/driverlib/asysctl.js");
    const led = scripting.addModule("/driverlib/board_components/led", {}, false);
    const led1 = led.addInstance();
    const clb = scripting.addModule("/driverlib/clb.js", {}, false);
    const clb1 = clb.addInstance();
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Alexey Zaparovanny
    TI__Mastermind 23230 points

    Hi Alexy,

    Your SysConfig configuration looks OK. Is the pull-up enabled when you change this GPIO to an input? If not, could you try enabling the pull-up to see if this issue persists?

    Why are you configuring the GPIO as an input if the mux selection is CLB Output XBAR?

    Thank you,

    Luke

  • 0 in reply to Luke Jones
    Prodigy 10 points

    I was not configuring GPIO as input i was trying to Tri-State output.Was just trying to bound the problem and to understand GPIO diagram, since i failed to route the same CLB output to GPIO41, not matter what settings i put into GPIO control registers. My experiments  showed VERY different behavior between GPIO32 and GPIO41, so something fundamental is either missing from the documentation or it's not very obvious. Thank you.

  • 0 in reply to Alexey Zaparovanny
    TI__Mastermind 23230 points

    Hi Alexey,

    Understood. I will test this issue on a F28P65x launchpad on my side. I should get back to you tomorrow.

    Thank you,

    Luke

  • 0 in reply to Luke Jones
    TI__Mastermind 23230 points

    Hi Alexey,

    I was able to replicate this issue on my side. While I was not able to send a CLB output to GPIO41, I was able to write to GPIO41 directly. I'll reach out to the design team to determine whether CLBOUTPUTXBAR2 is connected to GPIO41.

    Thank you,

    Luke

  • +1 in reply to Luke Jones
    TI__Mastermind 23230 points

    Hi Alexey,

    The design team confirmed that CLBOUTPUTXBAR2 is connected to GPIO41, however we realized that CLBOUTPUTXBAR2 is not connected to GPIO32, it is actually connected to GPIO33. CLBOUTPUTXBAR1 is connected to GPIO32. Just an FYI in case you were not aware of this already.

    I believe this is an issue in driverlib. When the XBAR_setOutputMuxConfig function is called, it takes in in XBAR_OutputNum struct as an input parameter. This struct is essentially an offset address to determine the register that gets written to, where CLBOUTPUTXBAR1MUX0TO15 has the same address as the base address for all CLBOUTPUTXBAR registers:

    The offset addresses should all be a multiple of two since there are two registers per CLBOUTPUXBAR instance. This function is shared between the CLB OUTPUTXBAR and OUTPUTXBAR modules.

    On F28P65x however, we updated the OUTPUTXBAR module to have 64 input muxes and 4 registers per OUTPUTXBAR instance, resulting in an update to the XBAR_setOutputMuxConfig function. However, the format of CLBOUTPUTXBAR remained the same(2 registers per CLBOUTPUTXBAR instance). So if you try to call this function(which SysConfig does) for CLBOUTPUTXBAR and use any CLBOUTPUTXBAR instance besides CLBOUTPUTXBAR1, the offset address used will be double what it should be. When you attempted to configure CLBOUTPUTXBAR2 via SysConfig, you were actually configuring CLBOUTPUTXBAR3 from a register perspective. This issue does not occur on CLBOUTPUTXBAR1 since the offset address is 0, so doubling the offset address will have no effect.

    I will work with the software team to have this fixed and included in our next C2000Ware release on April 5th. If you need to have this updated sooner, I can help you correct this on your side locally. Apologies for the inconvenience.

    Thank you,

    Luke

  • 0 in reply to Luke Jones
    Prodigy 10 points

    Hello Luke, thank you for investigating it, it makes sense now.  Short term i can just call driverlib with xbar offset divided by two, and it seems to be working:

    Fullscreen
    1
    XBAR_setOutputMuxConfig1(CLBOUTPUTXBAR_BASE, myCLB_OUTPUTXBAR1/2, XBAR_OUT_MUX00_CLB5_OUT0);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Alexey Zaparovanny
    TI__Mastermind 23230 points

    Hi Alexey,

    Glad to hear this workaround resolved the issue. Let me know if you have any additional questions.

    --Luke