• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 79 subscribers
  • Views 949 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.

RTOS/MSP432E401Y: driverlib SSI2 proper configuration for Quad-SSI

James McLaughlin
Expert 1090 points

Part Number: MSP432E401Y

Tool/software: TI-RTOS

I'd like to confirm my configuration is correct so that I'm running SSI2 in Quad-SPI read mode.  It seems I can get at least the SDO0 bit to read properly, but 1-3 don't do anything.  Either the GPIO configuration is wrong, the SSI configuration is wrong, or the device I'm operating isn't in QSPI mode like I think (but is as far as I can tell).

Here is my init function:

void initSSI2(void)
{
    Types_FreqHz F;
    BIOS_getCpuFreq(&F);

    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI2);
    while(!MAP_SysCtlPeripheralReady(SYSCTL_PERIPH_SSI2));

    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);
    while(!MAP_SysCtlPeripheralReady(SYSCTL_PERIPH_GPIOD));

    MAP_GPIOPinConfigure(GPIO_PD3_SSI2CLK);
    MAP_GPIOPinConfigure(GPIO_PD1_SSI2XDAT0);
    MAP_GPIOPinConfigure(GPIO_PD0_SSI2XDAT1);
    MAP_GPIOPinConfigure(GPIO_PD2_SSI2FSS);
    MAP_GPIOPinConfigure(GPIO_PD6_SSI2XDAT3);
    MAP_GPIOPinConfigure(GPIO_PD7_SSI2XDAT2);

    MAP_GPIOPinTypeSSI(GPIO_PORTD_BASE, GPIO_PIN_3 | GPIO_PIN_1 | GPIO_PIN_0 |
                           GPIO_PIN_2 | GPIO_PIN_6 | GPIO_PIN_7);

    MAP_SSIConfigSetExpClk  (   SSI2_BASE,
                            120e6,
                            SSI_FRF_MOTO_MODE_0,
                            SSI_MODE_MASTER,
                            20e6,
                            8
    );

    MAP_SSIAdvModeSet(SSI2_BASE, SSI_ADV_MODE_QUAD_READ);

    SSIAdvFrameHoldEnable(SSI2_BASE);

    MAP_SSIEnable(SSI2_BASE);
}

I have to first configure the slave device using SSI1 in legacy mode, then disable that entirely and switch over to SSI2.  The SSI1 initialization looks very similar, other than the specific pins and the SSI1 vs SSI2 references.

Does this look like the right way to configure it?

How can I verify the GPIO pins are set appropriately (the GPIO_DIR register in debug mode seems to indicate all pins are inputs, but that doesn't make sense)?

  • 0
    Expert 1090 points
    I'm currently testing with GPIODirModeGet and am getting unexpected results. Based on GPIOPinTypeSSI, I would expect all to return a 2 (for GPIO_DIR_MODE_HW), but they don't all return this.

    Pin - reply
    D3 - 0
    D1 - 2
    D0 - 2
    D2 - 0
    D6 - 0
    D7 - 0

    This indicates D3, D2, D6 and D7 are all set to inputs, while only D0 and D1 are under HW control.

    Is there a reason these wouldn't be set appropriately? Or they are, but it's just not returning the correct value?
  • 0 in reply to James McLaughlin
    TI__Guru 73421 points

    I am looking at the SPIFlash example, but not seeing anything significant other than the read to remove residual data from the SSI port.  I also noticed that there are several errata for the SSI module.

    I also found this discussion interesting:

    Regards,
    Chris

  • 0 in reply to Chris Sterzik
    Expert 1090 points

    Thanks for the validation on that and the extra info from that other post!  It turned out I wasn't configuring the slave device properly after all.

    Additionally, PD7 needed special handling to unlock configuring it properly, using GPIOLOCK and GPIOCR registers.  The GPIOAFSEL register (and a couple others) were indicating this pin wasn't configured properly, and that pin is listed in the discussion for GPIOAFSEL.

    I'm still curious why the GPIODirModeGet reply didn't reflect the configuration state of these pins as expected.  Digging into the code for that and comparing to the registers it's checking, it should have replied with all "2", indicating it was under peripheral control and reflecting the state of the AFSEL registers.

  • 0 in reply to James McLaughlin
    TI__Guru 73421 points
    James,
    Let me know if this is just a point of curiosity or if it is stopping you from making progress.

    Chris
  • 0 in reply to Chris Sterzik
    Expert 1090 points
    I suppose a little of both? I was able to move past since I was using it to verify registers I could check manually, but it wasted time and kind of defeats part of the purpose of using driverlib if I have to bypass it.

    Ideally I can use driverlib as much as possible, but I'd like to understand limitations where it might not read back register values properly. GPIODirModeGet seems to be an example of that when configured for SSI operation, unless it was just user error on my part that I'm not understanding.
  • 0 in reply to James McLaughlin
    TI__Guru 73421 points

    James,

       Check the pin channel number you are passing.  The naming convention for the pins is different from the GPIODirModeSet.

        testData[0] = GPIODirModeGet(GPIO_PORTD_BASE,7); //GPIO_PIN_7);
    testData[1] = GPIODirModeGet(GPIO_PORTD_BASE,6); //GPIO_PIN_6);
    testData[2] = GPIODirModeGet(GPIO_PORTD_BASE,3); //GPIO_PIN_3);
    testData[3] = GPIODirModeGet(GPIO_PORTD_BASE,2); //GPIO_PIN_2);
    testData[4] = GPIODirModeGet(GPIO_PORTD_BASE,1); //GPIO_PIN_1);
    testData[5] = GPIODirModeGet(GPIO_PORTD_BASE,0); //GPIO_PIN_0);

    I can see the subtle difference in the driverLib documentation.

    ui8Pins

    is the bit-packed representation of the pin(s).

    vs

    ui8Pin is the pin number.

    Hope that helps.

    Chris

  • 0 in reply to Chris Sterzik
    Expert 1090 points

    Ahhh, I see, that would do it!  I was indeed using the GPIO_PIN_x defines.  That's a tricky one.

    Thanks!

**Attention** This is a public forum