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.

TMS320F28335: Experimenter Kit

Part Number: TMS320F28335

Hi evrybody,
I am working on a SPI communication between two MCU (both are TI experimenter kit docking station with F28335 control Card). I want to transmit a discrete sin wave (50 Hz) and I want to receive that sin wave in another board and want to use it for other purpose. Now I am generating code for transmission of data in MATLAB 16a and using CCSV6. For receiving of data the code is generated by MATLAB 2011b and using CCSV4. Now the problem is that whenever I send DC values I am able to read the data in the other board and able to see it in the graph window of CCSV4. But whenever I want see a sin curve it will show something else rather than a sin curve. I am generating the sin curve (50Hz) in simulink having 5kHz sampling frequency. Now can anyone tell me that what could be the right settings for the two SPI transmit and receive block so that the sin wave can be received by the 2nd board is correct and without delay. And what could be the right settings should be done in the coder target option under configuration parameter pane so that my purpose will surve?

  • Hello,

    I am unfortunately unable to comment specifically on the MATLAB/ simulink issues. However, from a SPI perspective, the key for successful SPI communication is ensuring that the configurations match. The only difference between your master and slave configuration code will be the Master/slave bit.

    Can you add a little bit more detail on what you are seeing? is the received data just completely garbage? Adding some screen captures will help to give us some insight on the issue. I am going to request some assistance from Mathworks/Simulink. You might also get some help posting on the Mathworks forums as well.

    Thanks,
    Mark
  • You should definitely contact MathWorks Technical Support for assistance.

    Thanks,

    -Brian

  • Thank you Mark,

    I am sending you  the image file regarding the graph window of the sin wave. The unity amplitude sin wave has a DC offset of 1 and scaled by 0.5 so it is pulsating between 1 and 0.  The sin wave has the fundamental frequency of 50 Hz and sampled at 5kHz, so 100 samples in 20 milisec and I am assuming for each sample it will take 16 bits so 1600 bits has to be transfer in 20 milisec, so 80000 bits/sec.  Now in the case of any DC value it is showing currectly but in the case of a sin wave it is not coming. My Buffer-size for the graph window is 200 so I should see two full cycle.  I am setting the  LSPCLK of master as SYSCLK/4 and my SPIBRR is 127 while my slave has the SPIBRR as 127. FIFO has been enabled though no FIFO interrupt level  has been used.

  • Thank you Mark,

    I am sending you  the image file regarding the graph window of the sin wave. The unity amplitude sin wave has a DC offset of 1 and scaled by 0.5 so it is pulsating between 1 and 0.  The sin wave has the fundamental frequency of 50 Hz and sampled at 5kHz, so 100 samples in 20 milisec and I am assuming for each sample it will take 16 bits so 1600 bits has to be transfer in 20 milisec, so 80000 bits/sec.  Now in the case of any DC value it is showing currectly but in the case of a sin wave it is not coming. My Buffer-size for the graph window is 200 so I should see two full cycle.  I am setting the  LSPCLK of master as SYSCLK/4 and my SPIBRR is 127 while my slave has the SPIBRR as 127. FIFO has been enabled though no FIFO interrupt level  has been used.

  • Hi,

    It would be worth verifying that your data is being transmitted correctly (is the data correct going out of the transmitter?)

    Please try out Mathworks support first as Brian has mentioned. The code is being generated through the Mathworks tool chain So it is difficult to debug this on our end. If the issue turns out to be related to CCS, please respond back here and give an update.

    Thanks,
    Mark
  • Hi!

    I haven’t heard from you for a few weeks, so I’m assuming you were able to resolve your issue. If this isn’t the case, please reject this resolution or reply to this thread. If this thread locks, please make a new thread describing the current status of your issue.