• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 83 subscribers
  • Views 622 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.

CCS/LAUNCHXL-F28379D: LAUNCHXL-F28379D/BOOST-XL POSMGR -- SPI Ports Interfering with each other

Tyler Ambrico
Intellectual 315 points
Part Number: LAUNCHXL-F28379D


Tool/software: Code Composer Studio

Hello,

I'm trying to use the PM_BissC_System test project found in Control Suite to read a 26 bit encoder, then transmit the data from one launchpad to another using SPI-A. Data does transmit from one board to the other correctly, but when the data received by the second launchpad is sent to a DAC pin to view the output on an oscilloscope, it's apparent that the transmitted data frequently drops down to zero from the integer it was previously transmitting. If--instead of using the BissC project-- I use the SPI_loopback_cpu01 project in control suite (with the only modification of disabling loopback) to send integers 0-65535 linearly, this data drop problem still occurs. If I up the transmission baud rate by changing SPIBRR from 127 to 30, this data dropping phenomenon goes away. So, logically, I went back to the original scheme with the encoder hooked up and tried increasing the baud rate on SPI-A to get rid of the data drops. However, if I decrease SPIBRR past a value of 79, the PM_BissC_SystemTest code stops reporting position data.

Are the SPI-B and SPI-A ports between encoder/launch1 and launch1/launch2, respectively, interfering with each other if their baud rates get too close (i.e. if receive-from-encoder baud rate gets to close to transmit-to-launch2 baud rate)? I tried varying the receive baud rate on launch2 but this did not have much effect. Additionally, the CLK polarities for the spi-A and spi-B are reversed, but if I make them the same only garbage, nonsensical data gets transferred, with a lot of data drops.

How can I read the encoder via SPI-B and also transmit the data to another pad via SPI-A at sufficient data transmission rates such that these data losses do not occur? I attached a picture of the oscilloscope screen demonstrating the data drops.

Thanks for any help you can provide,

Tyler Ambrico

  • 0
    TI__Mastermind 24095 points
    Hi Tyler,

    Since you mentioned that "I use the SPI_loopback_cpu01 project in control suite (with the only modification of disabling loopback) to send integers 0-65535 linearly, this data drop problem still occurs."
    Did you run this test using only launch pad (no Booster Pack) and SPI_loopback_cpu01 testcase (not BiSS-C test)?
    If this is not the scenario, can you check in this configuration? This will help in isolating the problem to SPI interaction and LaunchPad only and rule out other aspects.
  • 0 in reply to Subrahmanya
    Intellectual 315 points
    Yes this is exactly what I did. I ran the SPI_loopback_cpu01 project (loopback disabled), and as I increased the baud rate the data drops went away. The boosterpack was still on the board but it wasn't initialized in the code, nor was the encoder LED on or anything (the spi_loopback code only sets the SPI-A pins high and nothing else).

    In fact, I was able to increase the baud rate a little bit when running the BissC_SystemTest project and this reduced the date drop rate (i.e. "frequency" of the green signal), but after a SPIBRR of about 79 the data transmission from the encoder stops working so I couldn't get it to go any faster.
  • 0 in reply to Tyler Ambrico
    TI__Mastermind 24095 points
    Is the waveform shown above reflecting transmitted data from SPI-A (dataout)?
    When you say data drops, are you observing any specific data bits going to zero all the time? Or is the whole data becoming zero?
    Also, just to isolate the problem and resolve any conflicts in the resources being used - can you remove the booster pack and try the launch pad only?
  • 0 in reply to Subrahmanya
    Intellectual 315 points
    Yes, what you are seeing in green on the scope is the data transmitted from SPI-A converted to an analog signal with DAC-B. By data drops I mean those dips you see on the green plot, where the voltage drops to zero. If I run the spi project and send over spi-A and set the baud rate high enough (like 40) these drops go away as you increase the baud rate.

    And as I said, I managed to make the data drops go away when running the spi loopback code with the boosterpack still on, so it shouldnt matter if the boosterpack is on or not. Besides, the boosterpack needs to be on if I'm going to be reading position...I will check if the data drops are present at a lower baud rate if I take the boosterpack off
  • 0 in reply to Tyler Ambrico
    TI__Mastermind 24095 points
    Hi,

    Did you get a chance to try the experiment without booster pack? Also can you share the configuration of GPIO ports used in your code?
    Are the low pulses indicated about are of 1 SPICLK wide? It seems like a proper data switching (though incorrect as you've noted) and does not seem to be case of signal coupling across SPIs.