TMS320F28375S: Issue with SPI Data Reception for SSI on TMS320F28375S

Hi Muzammil, 

I'm not sure I understand the complete issue here, feel free to elaborate if you can. But to clarify, are you saying the data does not fully match what was intended as in the data is shifted? Have you double checked that you are using the correct clock mode/SPI timings? Both devices need to agree on what clock mode etc. is being used (when data is being latched/received vs when data is being transmitted out). 

Best Regards,

Allison

Hello Allison,

I wanted to clarify the situation regarding the data being received from the encoder(AM4096). The encoder outputs data using the SSI protocol, as shown in the two images from my previous message. However, due to the high clock speed, I am receiving the data in the controller via SPI communication, as discussed in THIS THREAD(LINK).

The encoder provides data with a 12-bit resolution, ranging from 0 to 4095, as illustrated in the previous images. However, the data I am receiving through SPI ranges from 2048 to 4095, indicating that the Most Significant Bit (MSB) is always set to 1.

I suspect this issue arises because, when the clock goes low for the first time, no data is transmitted from the encoder (from point 1 to point 2 in the waveform in image shown below). The encoder begins sending data only after point 2. As a result, the MOSI pin of the SPI is high during this initial period (from point 1 to point 2 of the waveform), which the controller interprets as a data value of 1.

so, i think that the MOSI pin of SPI is high at that time(from point 1 to 2 of waveform) and it consider it as data which is 1.

so the data i am receiving is correct but the MSB is always 1 so i am getting data from 2048 to 4096.

Therefore, while the data I am receiving is technically correct, the consistent presence of the MSB being 1 leads to the erroneous data range of 2048 to 4095. 

Although I can obtain the correct data by subtracting 2048 from the received data and multiplying it by 2 to achieve the full range from 0 to 4095, I don't believe this is the proper method to retrieve the true data. Do you have any solutions or SPI configurations that would allow me to receive the data as it is being sent from the encoder, without any further calculations?

Additionally, the encoder is sending data in a format shown in the image I attached above. Could you please check page 11 of DATASHEET OF ENCODER for me? I would be very grateful for your assistance.

hope you understand the issue.

thanks and regards 

Muzammil Qureshi

Hi Muzammil, thank you for the clarification. 

Can you first please double check that your SPI clock mode is polarity = 1 and phase = 1? Looking at the encoder datasheet page 11, looks like the encoder expects idle-high clock with data transmitted on the rising clock edge and latched/received on the falling clock edge: 

Best Regards,

Allison

Hello Allison,

Allison Nguyen said:

Can you first please double check that your SPI clock mode is polarity = 1 and phase = 1?

Yes, I have checked, but the same problem is still occurring.

My SPI configurations are shown in the image below.

I have also checked all the other configurations i.e. all modes, all Emulation modes and high speed mode.

thanks and regards

Muzammil Qureshi

Hi Muzammil,

The clock mode should match now, so I don't think its a configuration issue. Can you try using SPI internal loopback mode (where TX and RX are tied together internally) to loop back the data and ensure you are receiving the complete data?

To clarify, are you saying that you see the full correct data being sent to the C2000, but it is being read incorrectly on the first bit? Or is the data that is being transmitted always have a 1 at the beginning? If the data transmitted is incorrect from the encoder, you may need to reach out to that device's team for guidance. If you increase the data size, do you still see a 1 at the beginning, but receive the full 12-bit data in the remaining data length?

Best Regards,

Allison

Hello Allison,

Allison Nguyen said:

To clarify, are you saying that you see the full correct data being sent to the C2000, but it is being read incorrectly on the first bit?

yes, this is what i am saying.

I have checked and received the data by manually toggling the clock pin to generate 12 pulses (the code is attached below).

uint16_t ReadPosition()
{
    uint16_t Sample = ShiftIn(SSI_Data, SSI_Clock, (uint8_t)12);
    DEVICE_DELAY_US(20);

    return Sample;
}

uint16_t ShiftIn(uint16_t data_pin, uint16_t clk_pin, uint8_t bit_count)
{
    uint16_t data = 0;
    uint8_t i;
    for(i=0; i<bit_count; i++)
    {
        data <<= 1;

        GPIO_writePin(clk_pin, 0);
        DEVICE_DELAY_US(1);
        
        GPIO_writePin(clk_pin, 1);
        DEVICE_DELAY_US(1);

        data |= GPIO_readPin(data_pin);
    }

    return data;
}

It produces the correct data; however, due to timing issues, I moved on to SPI.

I am confident that if the correct clock pulses are applied, there will be no issues with the encoder, and it will provide the correct data.

Thanks and Regards

Muzammil Qureshi

Hi Muzammil,

If the data is being sent correctly and the only issue is the clock on SPI, we are limited by the SPI clock mode hardware - there are only 4 clock modes available to be used. If none of the clock modes are compatible with the encoder device, then one more thought is if you can try using TXFIFO and adding the TXDLY:

I found a related thread on this - it was not resolved, but might yield some ideas for you: https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/981032/tms320f28379d-reading-the-angle-from-a-ssi-encoder-using-spi 

If none of these clock options work, then our SPI may not be compatible with this device. 

Best Regards,

Allison