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

SSI/SPI example works for internal loopback mode but not with an external loopback

Peter John
Expert 1480 points

Hi there,

I am using the LM4F232H5QD eval board.  I can successfully compile and debug/run the (slightly modified) example I obtained from here:

C:\StellarisWare\examples\peripherals\ssi\spi_master.c

2541.spi_master.c

The main difference between the example code and the code I'm attaching above is that I use SSI1 (not SSI0) and I enabled internal loopback with the following line of code so I could confirm it works OK.

//enable SSI (internal) loopback mode
HWREG(SSI1_BASE + SSI_O_CR1) |= SSI_CR1_LBM;

And it does loopback  OK !   Here is the UART/hyperterm output:

Sent:
's' 'p' 'i'
Received:
's' 'p' 'i' SSI ->
Mode: SPI
Data: 8-bit

However when I comment out that line and physically wire PF0 to PF1 (SSI0Rx to SSI0Tx) effecting an external loopback, I am unable to read any data back (the bytes are empty).    Note that I have left SSI0CLK  and SSI0Fss unwired at this stage.

rgds

Peter

  • 0
    Guru 26105 points

    Hi,

    PF0 pin needs a special treatment since it is also NMI pin - see paragraph 10.2.4 - Commit control in your user manual; you need to do the following:

    //
    // Enable port 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_DD;
    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);

  • 0 in reply to Petrei
    Guru 117855 points

    Agree w/poster Petrei - and direct you to the GPIO chapter w/in MCU datasheet.  There is a 2nd NMI "default" pin - and multiple other pins across several ports behave in, "non-standard (or non expected)" manner - from start-up. 

    Our group finds it beneficial to print this precautionary Pin Listing - and place it prominently @ each/every workstation.  (and of course JTAG pin caution must always be so listed...)

  • 0 in reply to Petrei
    Expert 1480 points

    Hi Petrei,

    You were 100% correct and this was the cause of my problem. Thank you for such a quick and accurate reply.

    I now have the physical loop-back working.  I note you probably obtained that code from the new PinMux utility for the M4F range of micros.  I can also recommend using that in future to avoid hassles like this.  In fact it would be even better if I didn't have to worry about this kind of low level configuration if  the Stellaris GPIOPinConfigure functions could detect and automatically cater for it.

    Note for completeness I also needed to 

    #include "inc/hw_types.h"

    so that the compiler recognised various symbols used such as GPIO_O_LOCK etc.

    Thank you also cb1_mobile for your comments.

    regards

    Peter