Problems with SPI communication between TM4C1236H6PM and Beaglebone Black (BBB)

Two of us spent a very frustrating day yesterday making no appreciable progress. As of this morning:

Interrupts are being triggered consistently, but not correctly when the Beaglebone writes out to the TM4C (RXTO).

The inclusion of UARTprintf statements did not alter the response from the device, so we are leaving them in for now to ease diagnostics.

If we send two 16-bit words from the BBB, the interrupt triggers (RXTO) as expected and two words are "read" from the FIFO. However, the result is always 0 no matter what we send to the TM4C. This is the same no matter which SSI peripheral is used (0, 1 or 2). The logic analyzer shows proper transmission at the input pins of the TM4C.

The interrupt is cleared and, even if we wait a number of cycles, the interrupt immediately triggers a second time but the status value is 0 when read. So why did it trigger?

I'm sending 0x1111 0x2222 (just the 0x1111 shown):

My output on the console is:

Our current, whittled down code just for testing the SPI comm from the BBB is as follows (many includes are left over from the larger program). Does anyone see any problem with this setup or have any suggestions? We can successfully read and write to ADCs and DACs from the Tiva TM4C using the same setup steps. It's communication with the BBB that is a problem.

#include <stdint.h>
#include <stdbool.h>
#include <stdio.h>
#include <stdlib.h>
#include "inc/hw_types.h"
#include "inc/hw_ints.h"
#include "inc/hw_memmap.h"
#include "inc/hw_gpio.h"
#include "inc/hw_ssi.h"
#include "inc/tm4c1236h6pm.h"
#include "driverlib/debug.h"
#include "driverlib/fpu.h"
#include "driverlib/ssi.h"
#include "driverlib/gpio.h"
#include "driverlib/interrupt.h"
#include "driverlib/pin_map.h"
#include "driverlib/sysctl.h"
#include "driverlib/uart.h"
#include "driverlib/adc.h"
#include "driverlib/timer.h"
#include "utils/uartstdio.h"
#include "driverlib/rom.h"

// Track the number of ISRs realated to SPI transmissions
uint32_t isr_counter = 0;

// This is the SPI receive array
#define NUM_SSI_DATA 8
uint32_t pui32DataRx[NUM_SSI_DATA];

void ConfigureUART(void) {
    // Enable the GPIO peripheral used bu the UART
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
    // Enable UART0
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);
    // Set GPIO A0 and A1 as UART0 pins.
    ROM_GPIOPinConfigure(GPIO_PA0_U0RX);
    ROM_GPIOPinConfigure(GPIO_PA1_U0TX);
    ROM_GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);
    // Use the internal 16MHz oscillator as the UART clock source.
    UARTClockSourceSet(UART0_BASE, UART_CLOCK_PIOSC);
    // Initialize the UART for console I/O.
    UARTStdioConfig(0, 9600, 16000000);
}

void SPI_ISR_Handler (void) {
    isr_counter++;
    char ISR_Rx_FIFO[12];
    uint32_t ui32Index = 0;
    uint16_t isr_source = SSIIntStatus(SSI0_BASE, 1);  //1 from true
    UARTprintf("ISR %d ---------- %d --------\r", isr_counter, isr_source);
    if (isr_source & SSI_RXTO) {
        UARTprintf("RXTO Trigger\r");
        while (SSIIntStatus(SSI0_BASE, 1) & SSI_RXTO) {
            SSIDataGetNonBlocking(SSI0_BASE, &pui32DataRx[ui32Index]);
            snprintf(ISR_Rx_FIFO, 12, "0x%0.8X", pui32DataRx[ui32Index]);
            UARTprintf("RXTO Reading %d: %s\r", ui32Index, ISR_Rx_FIFO);
            ui32Index++;
        }
        SSIIntClear(SSI0_BASE,  SSI_RXTO);
    }
    if (isr_source & SSI_RXFF) {
        UARTprintf("RXFF Trigger\r");
        for(ui32Index = 0; ui32Index < NUM_SSI_DATA; ui32Index++) {
            SSIDataGetNonBlocking(SSI0_BASE, &pui32DataRx[ui32Index]);
            snprintf(ISR_Rx_FIFO, 12, "0x%0.8X", pui32DataRx[ui32Index]);
            UARTprintf("RXFF Reading %d: %s\r", ui32Index, ISR_Rx_FIFO);
        }
        while(SSIBusy(SSI0_BASE)){}
        SSIIntClear(SSI0_BASE,  SSI_RXFF);
    }
    // Just for diagnostics while figuring this out...
    for(ui32Index = 0; ui32Index < 8; ui32Index++) {
        snprintf(ISR_Rx_FIFO, 12, "0x%0.8X", pui32DataRx[ui32Index]);
        UARTprintf("Value %d: %s\r", ui32Index, ISR_Rx_FIFO);
    }
    //wait a few cycles for the interrupt to clear
    ROM_SysCtlDelay(30);
}

//*****************************************************************************
//
//*****************************************************************************
int main(void) {

    //Set the clock internal to the Tiva to 40 MHz
    ROM_SysCtlClockSet(SYSCTL_SYSDIV_5|SYSCTL_USE_PLL|SYSCTL_XTAL_16MHZ|SYSCTL_OSC_MAIN);
    ROM_SysCtlPeripheralReset(SYSCTL_PERIPH_SSI0);
    

    // Enable necessary peripherals
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);         // UART, SPI0, ADC CONV, TP10
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI0);          // Enable SPI Port #1 (BBB communications)
    // GPIOA p0, p1 as UART0 -- Configure as B9600 8-N-1 tool
    ConfigureUART();
    

    //GPIOA p2, p3, p4, p5 as SPI communications (SPI0)
    GPIOPinConfigure(GPIO_PA2_SSI0CLK);
    GPIOPinConfigure(GPIO_PA3_SSI0FSS);
    GPIOPinConfigure(GPIO_PA4_SSI0RX);
    GPIOPinConfigure(GPIO_PA5_SSI0TX);
    GPIOPinTypeSSI(GPIO_PORTA_BASE,GPIO_PIN_5|GPIO_PIN_4|GPIO_PIN_3|GPIO_PIN_2);
    

    //Disable, configure, and enable the SSI controller
    SSIDisable(SSI0_BASE);
    ROM_SSIConfigSetExpClk(SSI0_BASE,SysCtlClockGet()/4, SSI_FRF_MOTO_MODE_0,SSI_MODE_SLAVE,500000,8);
    SSIEnable(SSI0_BASE);

    // ENABLE AN INTERRUPT ON THE SSI0 Rx FIFO
    IntRegister(INT_SSI0, SPI_ISR_Handler);
    IntEnable(INT_SSI0);
    SSIIntClear(SSI0_BASE, SSI_RXFF | SSI_RXTO | SSI_RXOR);
    SSIIntEnable(SSI0_BASE, SSI_RXFF | SSI_RXTO);
    IntMasterEnable();

    UARTprintf("Waiting for an SPI transmission.\r");

    while(1) {
    }
}

Has anyone successfully communicated from a BBB to a TM4C with the BBB configured as a master (mode 0) and the TM4C configured as the slave device?

Feel your pain - was going to ask "if" your logic analyzer is connected at the (proper) TM4C pins. (note that your 1st post places those facts in evidence) Is that still the case?

And - are you adequately powering both boards? Do both boards come up and go down - together?

Speed often is the enemy - suggest that you (significantly) reduce SPI speed - see if that helps.

You ask about BBB & TM4C. As you've multiple SPI ports on your TM4C (you mentioned trying multiple) would it not make sense to (temporarily) replace the BBB <-> TM4C with TM4C <-> TM4C - and test/observe? I'd bet that "that TM4C connection" is far more common than BBB - TM4C - and KISS dictates that small, simple steps lead best to a solution...  (i.e. too many "unknowns" in your current brew...)

Ryan Smith46 said:

Unfortunately I have only one board with the TM4C installed with which to work.

Believe ~14 (USD) and Digi-Key order can rectify (one board) only situation.

Or - with some monkey motion - you should be able to physically connect one SPI port as master - 2nd as slave - w/in your single MCU/board...  (gets the BBB out of the equation - believe that's been done here - don't believe that you want any "MCU automated" loop-back style connection...)

I do recall several posts here where users succeeded w/SPI on TM4C slave.   I'd search/find/model those - again devoid of BBB at this stage...

Is this not (still) more proof that the decision to default two (not just one) pin into NMI mode was short-sighted?   Is it possible that even 10% of the user-base know what NMI is - or its use - and pitfalls?   Might it be time to declare victory - and retreat?   (FIX this ongoing MESS!)
 
Years pass - issues remain - excelsior... (but not here...)

[edit] 27 May 2015: Poster earlier reported, "If we send two 16-bit words from the BBB, the interrupt triggers (RXTO) as expected and two words are "read" from the FIFO. However, the result is always 0 no matter what we send to the TM4C. This is the same no matter which SSI peripheral is used (0, 1 or 2)."

Thus - while the horror of PF0/PD7 has been allowed by vendor to long persist - ascribing the fault to, "simply PF0 was not being unlocked correctly" fails as PF0 is incapable of victimizing 2 of those 3 SSI peripherals!