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.

TM4C123G LaunchPad SSI2RX Strange Behavior

I have my LaunchPad configured with all SSI ports (0,1,2,3) enabled.  My code only exercises SSI3 at the moment.  If I monitor SSI3CLK with an oscilloscope and short SSI2RX (PB6) to ground, my SSI3CLK gets corrupted (runty, noisy clock only 500mV in amplitude).  Funny, SSI3FSS is unaffected.  Here's how my GPIOs are configured;


    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI2);
    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI0);
    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI1);
    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI3);
    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);
    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOC);
    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);
    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);

    //
    // Enable pin PA7 for GPIOOutput
    //
    MAP_GPIOPinTypeGPIOOutput(GPIO_PORTA_BASE, GPIO_PIN_7);

    //
    // Enable pin PB0 for GPIOOutput
    //
    MAP_GPIOPinTypeGPIOOutput(GPIO_PORTB_BASE, GPIO_PIN_0);

    //
    // Enable pin PB2 for GPIOOutput
    //
    MAP_GPIOPinTypeGPIOOutput(GPIO_PORTB_BASE, GPIO_PIN_2);

    //
    // Enable pin PB1 for GPIOOutput
    //
    MAP_GPIOPinTypeGPIOOutput(GPIO_PORTB_BASE, GPIO_PIN_1);

    //
    // Enable pin PC5 for GPIOOutput
    //
    MAP_GPIOPinTypeGPIOOutput(GPIO_PORTC_BASE, GPIO_PIN_5);

    //
    // Enable pin PC4 for GPIOOutput
    //
    MAP_GPIOPinTypeGPIOOutput(GPIO_PORTC_BASE, GPIO_PIN_4);

    //
    // Enable pin PC6 for GPIOInput
    //
    MAP_GPIOPinTypeGPIOInput(GPIO_PORTC_BASE, GPIO_PIN_6);

    //
    // Enable pin PA3 for SSI0 SSI0FSS
    //
    MAP_GPIOPinConfigure(GPIO_PA3_SSI0FSS);
    MAP_GPIOPinTypeSSI(GPIO_PORTA_BASE, GPIO_PIN_3);

    //
    // Enable pin PA4 for SSI0 SSI0RX
    //
    MAP_GPIOPinConfigure(GPIO_PA4_SSI0RX);
    MAP_GPIOPinTypeSSI(GPIO_PORTA_BASE, GPIO_PIN_4);

    //
    // Enable pin PA2 for SSI0 SSI0CLK
    //
    MAP_GPIOPinConfigure(GPIO_PA2_SSI0CLK);
    MAP_GPIOPinTypeSSI(GPIO_PORTA_BASE, GPIO_PIN_2);

    //
    // Enable pin PF3 for SSI1 SSI1FSS
    //
    MAP_GPIOPinConfigure(GPIO_PF3_SSI1FSS);
    MAP_GPIOPinTypeSSI(GPIO_PORTF_BASE, GPIO_PIN_3);

    //
    // Enable pin PF0 for SSI1 SSI1RX
    // First open the lock and select the bits we want to modify in the GPIO commit register.
    //
    HWREG(GPIO_PORTF_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY;
    HWREG(GPIO_PORTF_BASE + GPIO_O_CR) = 0x1;

    //
    // Now modify the configuration of the pins that we unlocked.
    //
    MAP_GPIOPinConfigure(GPIO_PF0_SSI1RX);
    MAP_GPIOPinTypeSSI(GPIO_PORTF_BASE, GPIO_PIN_0);

    //
    // Enable pin PF1 for SSI1 SSI1TX
    //
    MAP_GPIOPinConfigure(GPIO_PF1_SSI1TX);
    MAP_GPIOPinTypeSSI(GPIO_PORTF_BASE, GPIO_PIN_1);

    //
    // Enable pin PF2 for SSI1 SSI1CLK
    //
    MAP_GPIOPinConfigure(GPIO_PF2_SSI1CLK);
    MAP_GPIOPinTypeSSI(GPIO_PORTF_BASE, GPIO_PIN_2);

    //
    // Enable pin PB4 for SSI2 SSI2CLK
    //
    MAP_GPIOPinConfigure(GPIO_PB4_SSI2CLK);
    MAP_GPIOPinTypeSSI(GPIO_PORTB_BASE, GPIO_PIN_4);

    //
    // Enable pin PB5 for SSI2 SSI2FSS
    //
    MAP_GPIOPinConfigure(GPIO_PB5_SSI2FSS);
    MAP_GPIOPinTypeSSI(GPIO_PORTB_BASE, GPIO_PIN_5);

    //
    // Enable pin PB6 for SSI2 SSI2RX
    //
    MAP_GPIOPinConfigure(GPIO_PB6_SSI2RX);
    MAP_GPIOPinTypeSSI(GPIO_PORTB_BASE, GPIO_PIN_6);

    //
    // Enable pin PD0 for SSI3 SSI3CLK
    //
    MAP_GPIOPinConfigure(GPIO_PD0_SSI3CLK);
    MAP_GPIOPinTypeSSI(GPIO_PORTD_BASE, GPIO_PIN_0);

    //
    // Enable pin PD2 for SSI3 SSI3RX
    //
    MAP_GPIOPinConfigure(GPIO_PD2_SSI3RX);
    MAP_GPIOPinTypeSSI(GPIO_PORTD_BASE, GPIO_PIN_2);

    //
    // Enable pin PD1 for SSI3 SSI3FSS
    //
    MAP_GPIOPinConfigure(GPIO_PD1_SSI3FSS);
    MAP_GPIOPinTypeSSI(GPIO_PORTD_BASE, GPIO_PIN_1);

    //
    // Enable pin PD3 for SSI3 SSI3TX
    //
    MAP_GPIOPinConfigure(GPIO_PD3_SSI3TX);
    MAP_GPIOPinTypeSSI(GPIO_PORTD_BASE, GPIO_PIN_3);

Any thoughts?

  • Hello Greg,

    On the TM4C123 device I have used SSI2 and SSI3 and I have not encountered such a behavior. However since you are facing an issue, can you please check the following

    1. Is the behavior reproducible with PB6 as a GPIO and being driven logic 1 or 0?

    2. What happens of PB6 in SSI mode is connected to 3.3V

    Regards

    Amit

  • On the launchpad PB7 is shorted to PB6 for compatibility purposes (a pain if you ask me)

    Also PD1 and PD0 are shorted for the same reason

    There are 2, 0 ohm resistors bellow the chip (facing the programmer up) that do that

  • Hello Luis,

    Thanks for the catch (skipped the 0Ohms). One correction it is PB6 to PD0 and PB7 to PD1

    Regards

    Amit

  • hi amit,

    thanks, i never quite remember which one they are connect to (i don't use bosterpacks so i simply take the resistors right away)

  • As past suggested (over a year ago) those 0-ohm resistors would prove so less troublesome if they were included in a small bag - not "installed" - for the 90%+ of users here who neither are aware of - nor seek - any past MSP compatibility. 

    Maddening that "high value" forum name change receives time/effort/consideration - "fix" of this unwanted 0-ohm resistor issue - merely "duly noted."  (i.e. do nothing - same complaint - and rejected suggestions - plague most all users via PF0/PD7!)

    All hail the most vital, "name change!"  Seriously - how does such torment/frustration of users aid Sales/Marketing?

    Poster called this behavior, "Strange" - clearly that's not close to true!  Behavior has long been "known" - was predictable from the outset - and allowed (far too long, I'd say) to continue... 

  • My small note about those kind of problems on my work desk is running out of space, maybe a full A4 will be enough

  • Luis Afonso said:
    My small note about those kind of problems on my work desk is running out of space

    Ha!  Very cleverly stated my friend, Luis.

    Be sure to leave much space for that vital, "Forum Name Change" which surely will land w/out hiccup & grave issues.  (i.e. NOT like the roll-out of the replacement to robust, MCU to MCU consistent, bullet-proof, StellarisWare - or the "smooth decoupling" of LM3S or...(fill in the blanks))

    Big brother knows best - except when he does not...  Fixing real - long lingering - known tech problems should trump any "bandaid Forum name change" most of our clients - and my team - believe...