cancel
Showing results for 
Search instead for 
Did you mean: 

Ambiguous data over MISO Line SPI Communication (Master mode).

AT.8
Associate II

Hi all,

I am using STM32F334 for SPI communication with a TDC7201 chip from TI.

I am using the Low-Level Drivers to initialize the driver and communicate.

Here is my initialisation routine:

    __HAL_RCC_SPI1_CLK_ENABLE();
 
    LL_SPI_InitTypeDef SPI1InitStruct;
 
    SPI1InitStruct.BaudRate          = LL_SPI_BAUDRATEPRESCALER_DIV4;
    SPI1InitStruct.ClockPhase        = LL_SPI_PHASE_2EDGE;
    SPI1InitStruct.ClockPolarity     = LL_SPI_POLARITY_HIGH;
    SPI1InitStruct.CRCCalculation    = LL_SPI_CRCCALCULATION_DISABLE;
    SPI1InitStruct.DataWidth         = LL_SPI_DATAWIDTH_16BIT;
    SPI1InitStruct.TransferDirection = LL_SPI_FULL_DUPLEX;
    SPI1InitStruct.BitOrder          = LL_SPI_MSB_FIRST;
    SPI1InitStruct.Mode              = LL_SPI_MODE_MASTER;
    SPI1InitStruct.NSS               = LL_SPI_NSS_SOFT;
 
    LL_SPI_Init(SPI1, &SPI1InitStruct);
    LL_SPI_Enable(SPI1);

I have initialized the port PIns so:

/**
     * PB3  - SCK
     * PB4  - MISO
     * PB5  - MOSI
     * PA15 - NSS
     */
 
    if (RESET == __HAL_RCC_GPIOB_IS_CLK_ENABLED())
    {
        __HAL_RCC_GPIOB_CLK_ENABLE();
    }
 
    LL_GPIO_InitTypeDef gpioSPIInitStr;
 
    gpioSPIInitStr.Alternate = LL_GPIO_AF_5;
    gpioSPIInitStr.Pin       = LL_GPIO_PIN_3 | LL_GPIO_PIN_5;
    gpioSPIInitStr.Mode      = LL_GPIO_MODE_ALTERNATE;
    gpioSPIInitStr.Speed     = LL_GPIO_SPEED_FREQ_HIGH;
    gpioSPIInitStr.Pull      = LL_GPIO_PULL_NO; // LL_GPIO_PULL_NO; //
                                                // LL_GPIO_PULL_UP
    gpioSPIInitStr.OutputType = LL_GPIO_OUTPUT_PUSHPULL;
 
    LL_GPIO_SetAFPin_0_7(GPIOB, LL_GPIO_PIN_3, LL_GPIO_AF_5);
    LL_GPIO_SetAFPin_0_7(GPIOB, LL_GPIO_PIN_4, LL_GPIO_AF_5);
    LL_GPIO_SetAFPin_0_7(GPIOB, LL_GPIO_PIN_5, LL_GPIO_AF_5);
 
    LL_GPIO_Init(GPIOB, &gpioSPIInitStr);
 
    // Pin B4 (MISO) must be configured as as input pull-up
    LL_GPIO_StructInit(&gpioSPIInitStr);
    gpioSPIInitStr.Pin   = LL_GPIO_PIN_4;
    gpioSPIInitStr.Mode  = LL_GPIO_MODE_INPUT;
    gpioSPIInitStr.Pull  = LL_GPIO_PULL_NO;
    gpioSPIInitStr.Speed = LL_GPIO_SPEED_FREQ_HIGH;
    LL_GPIO_Init(GPIOA, &gpioSPIInitStr);
 
    /*NSS Pin Config */
    LL_GPIO_InitTypeDef SPI_SSPIN_Struct;
 
    SPI_SSPIN_Struct.Mode       = LL_GPIO_MODE_OUTPUT;
    SPI_SSPIN_Struct.OutputType = LL_GPIO_OUTPUT_PUSHPULL;
    SPI_SSPIN_Struct.Pin        = LL_GPIO_PIN_15;
    SPI_SSPIN_Struct.Speed = LL_GPIO_SPEED_FREQ_HIGH;
 
    LL_GPIO_Init(GPIOA, &SPI_SSPIN_Struct);
    LL_GPIO_SetOutputPin(GPIOA, LL_GPIO_PIN_15);

This is how my "read_register " routine looks like:

uint16_t read_register(uint8_t address)
{
	uint16_t data;
        uint8_t raddr;
 
	if (!LL_SPI_IsEnabled(SPI1))
        {
	    LL_SPI_Enable(SPI1);
        }
        raddr = address; // set addr bits 7 & 6 to 0 for read
        CHIP_SEL_LOW(); // slave select (low)
 
        while (!LL_SPI_IsActiveFlag_TXE(SPI1))
          ; // wait while not empty
 
        LL_SPI_TransmitData16(SPI1, (uint16_t)(raddr<<8));
 
        while (!LL_SPI_IsActiveFlag_RXNE(SPI1))
          ; 
        data = LL_SPI_ReceiveData16(SPI1);
         while (LL_SPI_IsActiveFlag_BSY(SPI1))
               ; 
    CHIP_SEL_HIGH(); // slave deselect (high)
 
    if (LL_SPI_IsEnabled(SPI1))
    {
    	LL_SPI_Disable(SPI1);
    }
    return data;
}

I try to read the contents in 2 registers periodically in the main routine.

var1 = read_register(0x00);
Delay_us(500);
 
var2 = read_register(0x03);
Delay_us(500);

I read 0xFFFF in both var1 and var2 , always. When i know for sure that the content is different.

This is how my transaction looks on the scope. Clock (Red), CS (Blue), MOSI(Green), MISO (Yellow).

0693W00000KaEQFQA3.png 

0693W00000KaET9QAN.png 

The signal on MISO and the received data are not as expected, I don't understand why. I believe i am doing something wrong in the initialization stage. Any useful tips or pointers would be helpful. Thanks.

15 REPLIES 15
TDK
Guru

Looks like the chip isn't driving the line at all. Use a weak pulldown on the line to see if it changes the value from 1s to 0s. If it does, it means you likely have a hardware problem. Consider lowering clock speed as well during debugging to eliminate that as a possible issue, especially if you have long leads.

If you feel a post has answered your question, please click "Accept as Solution".

Tell us more about your hardware.

TDC7201 is a nasty BGA package. I'm willing to bet that there are bad connections in the way.

JW

AT.8
Associate II

I'm sure that the TDC Eval Board is fine. I have tested its working using a TI MSP board. But the board was plugged in directly to the TI board via connector socket. So, no wires, it was directly plugged in.

The wires that are connected to TDC board from ST board are not more than 15 cm. Ok i will try using a pull down. I have tried lower baudrates (125k and 250k), with no luck, unfortunately.

I'm using STM32F334 Discovery board and the TDC 7201 Eval board (https://www.ti.com/tool/TDC7201-ZAX-EVM).

SPI and Enable connection are established using male-female jumper wires (15 cm long).

When the TDC Eval board is directly plugged in to TI MSP Eval board, it works as expected. The data on MISO line in this case, make complete sense.

OK so I've lost the bet with the BGA, bad connection still may be the issue.

Shorten wires, decrease slew rate in GPIO_OSPEEDR, and use return (ground) for every signal (twist if possible).

Make sure you didn't swap MISO and MOSI.

Measure directly on TI devboard. Compare waveforms taken with the TI master versus with STM32.

JW

Thank you for the helpful tips, I will definitely try to reduce the wire length as far as possible. I have compared the waveform with the TI, Clock, CS and MOSI are identical. Vcc was slightly different 3.277V with TI and 3.312 with ST. And of course the MISO Line was not a noisy high signal, instead there was a valid data returning on that line.

Is the ST software ok in your opinion?

Kraal
Senior III

Hi,

I think I found the issue.

In your port pin initialization LL routine, line 35

it should be LL_GPIO_Init(GPIOB, &gpioSPIInitStr);

You put GPIOA instead. So PB4 has not been initialized correctly.

Kraal

AT.8
Associate II

Yes, you are right, this was not initialized correctly, but it does not change anything, unfortunately. I'm not even sure if that part was necessary? To configure PB4 as Input.

> To configure PB4 as Input.

No, it should be AF; nonetheless that would have no impact on the waveform.

Do you measure the waveforms directly on the TI board?

JW