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.

TM4C1294NCPDT: Problem interfacing with BOOSTXL-ADS7841-Q1 through SPI

Part Number: TM4C1294NCPDT

Hello all,

First I foremost I want to say that I have reach out to the Digital Converter forum and I didn't receive much help over there and my problem is still going on. I've stuck for 3 days so I decided to come here and ask for help.

Like the title says, I am interfacing with the BOOSTXL-ADS7841-Q1. This is the data sheet of the device for your convenience.

Secondly, the current behavior of my application can be explained through the Timing Diagram as follow.

Per the diagram, the BUSY and DOUT go low as soon as the CS goes low. My DOUT and BUSY is currently stay low all the time.

This is the screen shot of the scope with the Control Byte0x97 and the subsequent two bytes 0x00 and 0x00 to generate the clock for the DOUT to send in the data.

Here is the message frame.


And now is the same message frame but with the BUSY line.

Below is my code

/*
 * src_ads8741.c
 *
 *
 *      The device is using SSI2 of TM4C1294 Pin assignment is as follow:
 *      SPI MOSI - PQ2 - SSI3XDATA0
 *      SPI MISO - PQ3 - SSI3XDATA1
 *      SPI SCL  - PQ0 - SSI3SLCK
 *      SPI ~CS  - PM7 - CHIP SELECT
 *      ADS BUSY - PP3 - BUSY PIN
 */


#include "src_ads8741q1/src_ads8741q1.h"
#include "src_mk_led/mk_led_control.h"

uint32_t pui32DataRx[16];

void init_ads7841q1(uint32_t sysClock) {

    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI3);
    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOQ);
    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOM);
    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOP);

    //  Configure SSI3 pins
    MAP_GPIOPinConfigure(GPIO_PQ0_SSI3CLK);
    MAP_GPIOPinConfigure(GPIO_PQ2_SSI3XDAT0);   //MISO
    MAP_GPIOPinConfigure(GPIO_PQ3_SSI3XDAT1);   //MOSI
    MAP_GPIOPinTypeSSI(GPIO_PORTQ_BASE, GPIO_PIN_0 | GPIO_PIN_2 | GPIO_PIN_3);

    //  Setup SPI: 2MHz, 8 bit data, mode 0
    MAP_SSIClockSourceSet(SSI3_BASE, SSI_CLOCK_SYSTEM);
    MAP_SSIConfigSetExpClk(SSI3_BASE, sysClock, SSI_FRF_MOTO_MODE_0,
                           SSI_MODE_MASTER, 2000000, 24);
//    MAP_SSIAdvModeSet(SSI3_BASE, SSI_ADV_MODE_LEGACY);
    MAP_SSIEnable(SSI3_BASE);

    //  Empty receiving buffer
    uint32_t dummy[1];
    while (MAP_SSIDataGetNonBlocking(SSI3_BASE, &dummy[0]));

    //  Configure chip select pin
    MAP_GPIOPinTypeGPIOOutput(GPIO_PORTM_BASE, GPIO_PIN_7);
    ads7841q1_chip_select(UNSELECT);
    // Configure BUSY pin
    MAP_GPIOPinTypeGPIOInput(GPIO_PORTP_BASE, GPIO_PIN_3);
}

void ads7841q1_read_data() {
    uint32_t buffer_data[3] = {0, 0, 0};
    MAP_GPIOPinWrite(GPIO_PORTM_BASE, GPIO_PIN_7, 0);

    /* Send In Control Byte */
    SSIDataPut(SSI3_BASE, 0x97);
    SSIDataGet(SSI3_BASE, &buffer_data[0]);

    SSIDataPut(SSI3_BASE, 0x00);
    SSIDataGet(SSI3_BASE, &buffer_data[1]);

    SSIDataPut(SSI3_BASE, 0x00);
    SSIDataGet(SSI3_BASE, &buffer_data[2]);
    while(SSIBusy(SSI3_BASE)){}


    MAP_GPIOPinWrite(GPIO_PORTM_BASE, GPIO_PIN_7, GPIO_PIN_7);

}

void ads7841q1_chip_select(CHIP_SELECT option) {
    if (option == SELECT) {
        MAP_GPIOPinWrite(GPIO_PORTM_BASE, GPIO_PIN_7, 0);
        set_board_led(BOARD_LED_1, LED_ON);
    } else if (option == UNSELECT) {
        MAP_GPIOPinWrite(GPIO_PORTM_BASE, GPIO_PIN_7, GPIO_PIN_7);
        set_board_led(BOARD_LED_1, LED_OFF);
    }
}

void ads7841q1_check_busy() {
    if(GPIOPinRead(GPIO_PORTP_BASE, GPIO_PIN_3) == GPIO_PIN_3) {
        set_board_led(BOARD_LED_2, LED_ON);
    } else {
        set_board_led(BOARD_LED_2, LED_OFF);
    }
}

I've try different mode .i.e SSI_FRF_MOTO_MODE_0 through SSI_FRF_MOTO_MODE_3 

In the main.c the I initialize the function init_ads7841q1() before the while loop and put the ads7841q1_read_data() inside the while loop to generate the communication.

The strange things is that the application works just find when using the GUI application come with the booster pack but doesn't work with my application. I don't know what I miss and I am desperate...

I really appreciate the help from you guys.

Let me know if you need me to provide with more information.

Thanks,

Alex

  • Hello Alex,

    Do you believe the issue to be with the SPI implementation of the TM4C? To me it sounds like the SPI is working fine but you are just not able to get the slave device to reply, is that correct?
  • Hello Raplh,

    Thank you for replying in this late hour.

    I believe that I have the SPI configure correctly, but the result is not as I expected so I have doubt in that too.

    Alex
  • Hi Hau,

    Since you have SPI data going out, you are most of the way there on the TM4C configuration, but I do see a couple issues with the capture you shared vs the timing diagram:

    1) It clearly looks from the datasheet that the slave device samples data on the Rising edge of the clock, but you're capture shows data on the Falling edge of the clock. Based on the D/S specs, you need to use SSI_FRF_MOTO_MODE_0, and with that the TM4C configuration should be fine.

    2) From what I can see, you should be using 8 byte transactions, not 24 byte transactions. The DS states 24 clock conversions per cycle, but only an 8-bit bus. So I would adjust that as well.

    Beyond doing those changes, unfortunately I think you will need to get advice from the folks at the data converters forum. But if you are not getting replies by Monday afternoon, please post here again with the thread you aren't receiving support on and I can try and help get your question on that forum escalated. I say Monday afternoon because it is the weekend now and while I am one of the crazy guys who posts on the weekend, not everyone does :).
  • Ralph,

    Thank you so much for the response.

    I've managed to figure out the problem. The ~SHDN pin was always pulled low due to the board hardware problem.

    I followed the schematic in datasheet which it tells me the ~SHDN pin is always pulled high to prevent the chip goes into shutdown mode.  I guess I cannot trust the schematic so blindly next time.

    When I manually applied the VCC into the chip, it gave me the correct output. Now I just need to find the way to bypass this issue.

    God bless you guys!

    Alex