• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 33 subscribers
  • Views 242 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.

TMDSCNCD263P: FSI Pinmux Issues

Jared Weyer
Prodigy 126 points
Part Number: TMDSCNCD263P
Other Parts Discussed in Thread: SYSCONFIG, AM263P4

Hi,

I originally posted this in the incorrect forum (TMDSCNCD263P: FSI Pinmux). Apologies for the duplicate, but figured I would repost here: 

I am working on getting FSI working on the AM263 control card. I have a very simple program running, which simply sends a ping frame and receives it:

        /* send ping frame*/
        status = FSI_setTxFrameType(txBaseAddr, FSI_FRAME_TYPE_PING);
        status += FSI_setTxFrameTag(txBaseAddr, FSI_FRAME_TAG1);
        status += FSI_startTxTransmit(txBaseAddr);
        status += SemaphoreP_pend(&gFsiTxSemObject, ClockP_usecToTicks(FSI_TX_TIMEOUT_US));
        if(status != SystemP_SUCCESS)
        {
            DebugP_log("failed to send ping frame\r\n");
            continue;
        }
        DebugP_log("sent ping frame\r\n");
        /* receive ping frame*/
        status += SemaphoreP_pend(&gFsiRxSemObject, ClockP_usecToTicks(FSI_RX_TIMEOUT_US));
        status += FSI_getRxFrameType(rxBaseAddr, &frameType);
        status += FSI_getRxPingTag(rxBaseAddr, &rxFrameTag);
        if (status != SystemP_SUCCESS)
        {
            DebugP_log("failed to receive ping frame\r\n");
            continue;
        }
        DebugP_log("received ping frame: frame tag = %u\r\n", rxFrameTag);
 
The program runs flawlessly when running in loopback mode; however, when I short rx to tx with jumper wires, and run in normal mode, the program does not work (no ping frame is received). 
My guess is that this is a pinmux issue since loopback mode bypasses the pinmux; however, I can't seem to find anything wrong with my setup. FSI signals are muxed with MCAN signals, but FSI is default because of the pull-up resistor on FSI_MUX_SEL. By the way, this documentation is incorrect (the pull-down resistor is not populated):
The MCAN signals go through a 1:2 signal routing mux. There is a pull-down resistor on the select line of the mux and therefore the MCAN signal routing is the default. 
I am also fairly certain that my AM263 Pinmux is setup correctly.  From the PROC1592E2 schematic:
 
FSIRX2_CLK J2
FSIRX2_DATA0 G4
FSIRX2_DATA1  J3
 
FSITX2_CLK G3
FSITX2_DATA0 H2
FSITX2_DATA1 G1
 
Sysconfig setup:

fsirxsyscfg.png
fsitxsyscfg.png
 
I also don't think there is anything wrong with my interrupt setup because I don't believe the loopback program would work if there was something misconfigured here. 
 
Am I missing something? Any recommendations on where to look next?

Thanks,
 
-Jared
  • 0
    Intellectual 696 points

    I'm having the same issue as Jared. This can be duplicated easily using an AM263P4 control card (mine is revision PROC159B(001)) and MCU+ SDK v11.00.00.19.

    Load example "FSI Loopback Interrupt". Make the following changes:

    1. In sysconfig, change FSI TX and RX pinmux to match the AM263P4 control card (RX_CLK = ball J2, RX_DATA0 = ball G4, TX_CLK = ball G3, TX_DATA0 = ball H2)

    2. In file fsi_loopback_interrupt.c replace "FSI_enableRxInternalLoopback" with "FSI_disableRxInternalLoopback"

    3. On the ControlCard, use shunt jumpers to short TX CLK to RX CLK (pin 1 to 2) and TX DATA0 to RX DATA0 (pin 5 to 6) on header J6. 

    With those changes I see the same result as Jared, which appears like FSI RX2 isn't receiving. Using an oscilloscope I see TX clock and data on J6 pins 2 and 6, and the example runs successfully in loopback mode. But when loopback is disabled the program hangs forever waiting for an RX interrupt.

  • 0 in reply to Steven Hansen
    TI__Genius 12359 points

    Hi Jared, Steven,

    First, I will confirm what you have already stated, just so there is no confusion:

    1. The MUX U33 selects between the routing of the MCAN or FSI signals to their respective interfaces. FSI is selected by default, as the pull-up resistor R204 routes the A->B2 ports of the mux. 
      1. However, the initial revision of this board, Rev E1 had the opposite of this, where the pull-down resistor was populated by default. It is worth checking the SysConfig settings for the IO Expander that controls the select signal of this mux to ensure that it is being pulled HIGH in software as well:
    2. Verifying the MCU PinMux:
      1. Signal MCU Pin
        FSIRX2_CLK J2
        FSIRX2_DATA0 G4
        FSIRX2_DATA1 J3
        FSITX2_CLK G3
        FSITX2_DATA0 H2
        FSITX2_DATA1 G1
      2. This all looks fine in your SysConfig screenshots that you sent.

    Please confirm the MUX SEL configuration in SysConfig to rule out any issues with the MCU PinMux or board-level signal configuration.

    Regards,

    Brennan 

  • 0 in reply to Brennan Hartigan
    Prodigy 126 points

    Hey Brennan,

    Thanks for getting back to me on this. I verified that correct pull-up resistor is populated; however, we setting the FSI mux selected in software via sysconfig. I attempted to update sysconfig with the correct FSI mux select, but the code is now hanging on I2C_transfer(). I assume this is due to improper I2C setup in sysconfig. 

    Do you see any issues with my sysconfig setup?

    Thanks for your help,

    Jared

  • 0 in reply to Jared Weyer
    TI__Genius 12359 points

    Jared, 

    I2C2 is the I2C peripheral that is connected to the IO Expander. You need to configure:

    • I2C2_SCL on C7
    • I2C2_SDA on B7

    Let me know if the I2C transfer now goes through.

    Regards,

    Brennan

  • 0 in reply to Brennan Hartigan
    Prodigy 126 points

    Still seems to be hanging on the I2C transfer after the changes.

    Here is a link to my project. 

  • 0 in reply to Jared Weyer
    TI__Genius 12359 points

    Hi Jared,

    Can you upload the project files to this thread as a zip folder? I can't access the dropbox. I will replicate on my side and report back any findings (likely tomorrow).

    Regards,

    Brennan

  • 0 in reply to Jared Weyer
    TI__Genius 12359 points

    Hey Jared,

    I don't have this completely solved yet, but I want to share an update:

    1. Even with the correct on-board mux/MCU pinmux settings for FSI, I could not get the external loopback on the on-board J6 header working.
    2. However, the example for external loopback runs fine if I plug the control card into a docking station, and use FSI pins that do not go through any muxing:
      1. If you have a docking station and want to continue your development, I have attached the SysConfig settings for FSI RX/TX here. For these signals, the traces do not go through any external muxing - the connection is direct from the MCU to the edge connector. The HW connections you need to make are: 
        1. CLK: HSEC_59 <-> HSEC_58
        2. D0: HSEC_61 <-> HSEC_60
        3. D1: HSEC_63 <-> HSEC_62
      3. SysConfig:

    I am going to continue to look into as to why this isn't working on the on-board header, but I wanted to provide a temporary solution in the mean time and validate that the software itself is fine.

    Regards,

    Brennan

  • 0 in reply to Brennan Hartigan
    Prodigy 126 points

    Hey Brennan,

    Interesting! I have a docking station I will try replicating your setup and let you know if I can reproduce.

    Were you able to get the I2C transfer to work without hanging? Just curious if you are still thinking that this is an issue with the software FSI MUX SEL.

    Thanks again,

    Jared

  • +1 in reply to Jared Weyer
    TI__Genius 12359 points

    Jared,

    Mystery solved here. The root cause is that the 3V3 net that the pull-up on that mux select net is connected to does not come up by default when power is given to the EVM. This power net comes from a non-default PMIC LDO output.

    I am able to run the example using the on-board header by first configuring the PMIC to enable this LDO (LDO2). I have attached the CCS file to do this.

    Then, assert PORz using the SW10 push-button. Lastly, run the FSI External loopback example. 

    As long as you do not remove power from the EVM, this LDO2 will remain on.

    pmic_user_reg_cfg_am263px-cc_r5fss0-0_nortos_ti-arm-clang.zip

    Regards,

    Brennan