TMS320F280041C: SPIB looped internally

Part Number: TMS320F280041C

Tool/software:

Greetings! I`m using spi_ex1_loopback as a reference. My pins are connected as follows-> SIMO->GPIO56 MOSI->GPIO57, CLK->GPOI58. So with Loopback enabled(SpibRegs.SPICCR.bit.SPILBK=1;) everything works as expencted. So I disabled the loopback(SpibRegs.SPICCR.bit.SPILBK=0;) and tried to establish real communication. The problem is that the line transmition is working correctly(F280041C sends data and the connected chip responces properly), but in the SpibRegs.SPIRXBUF I have the same value as transmitted(not the send value from the slave). SpibRegs.SPIRXBUF=SpibRegs.SPITXBUF. It acts like the loopback is enabled. Which is not set. I checked the registers. The GPOI settings are the same as the example. The only difference is that I have changed the GPOI numbers accordin to the pinout above.

Any suggestions? Is there a possiblity the problem to be in the MUX. The pins to be looped using GPIO settings? As I said the line is working correctly. I has to be some internal setting.

Thanks!

  • Hello,

    Apologies for some delay. Can you verify that your SPI lines reflect this same behavior? Have you scoped these lines already? 

    Also be sure to check the SPI RX EMU registers if you are viewing in CCS registers window.

    Best Regards,

    Allison

  • So I setup SPIA using the same example spi_ex1_loopback. I am using GPI16, GPIO10 and GPIO9. Again the loop flag is 0, but somehow the SPI interface is looped back internally. Is there a possiblity this to happen in the MUX?

    Thanks!

  • Hi Pavlin, 

    If you do not enable loopback mode in the SPI and do not have a hardware connection, this should not be occurring in the SPI. Can you please double check your GPIO registers match what is expected? What code are you using for your GPIO initializations? Can you confirm the following as well for my clarity (specifically, the chip select pin):

    • GPIO16 --> SPI SIMO
    • GPIO10 --> SPI SOMI
    • GPIO9 --> SPI CLK
    • GPIO_ --> SPI STE?

    I see you are using the example as a reference. What type of data are you transmitting/receiving? Have you tried using the example with the only change being disabling loopback mode?

    Again, it would be helpful to check an analyzer or oscilloscope to sanity check everything looks ok as well.

    Best Regards,

    Allison

  • Hi! here is an update on the case. It seems I had somekind of a version issue. So I have the last spi_ex1_loopback. My pins are as it follows:

    SPI_SIMO=>GPIO56;

    SPI_MOSI=>GPIO57;

    SPI_CLK=>GPIO58;

    SPI_STE=>GPIO27;

    When I am in 16 bit mode everything works just fine. I removed the loopback flag just to confirm the line with my logic analyzer. So I can monitor the output data and when I tide GPIO56 and GPIO57 together I can loopback the data on hardware level. The STE signal is responding accordingly. Everything is just fine here.

    BUT when I select 8 bit mode I don`t transmit anything on the line. When the loopback flag is set I can`t execute the program. I receive sData!=rData error. 

    I tried to shift right the result from SPI_readDataBlockingNonFIFO(mySPI0_BASE);

    rData =rData >>8;

    but it seems this works only on the controller and still there is nothing on the line.

    Any idea?

    Thanks!

  • Hi Pavlin,

    The SPIDAT register is a shift register. During transmission, the data at the MSB will be shifted out first. For 8-bit characters, you have to shift the data to the left by 8 bits so that the 8-bit data is shifted out correctly. Otherwise, if you were to write 0x00FF to the SPIDAT to transmit, this will only transmit 00. 

    When receiving, the data is received into the lower 8 bits of the buffer so no need to bit-shift upon receival.

    Please confirm if you are shifting before transmitting in 8-bit mode.

    Best Regards,

    Allison

  • I fixed it! This was a good note! So my problem came from that I have forgotten the 3 wire mode doesn`t mean 3 data sygnals but only 2 with STE. And when I enable this mode this somehow shorted the SIMO and  MISO signals internally. And because the slave device doesn`t work with STE signal - it has to be set permanently low in order to respond correctly - this made the mess.

    Thanks!

  • Pavlin, Glad to hear you were able to fix it! Thanks for posting other info on the resolution as well Slight smile I will close this thread. Feel free to open a new one should other issues arise.

    Best Regards,

    Allison