TMS570 SPI Interface SPI1 SIMO[1]

Hi Robert,

 The SPI1SIMO[1]/SPI1SOMI[1] are only utilized when the SPI is configured for parallel mode operation. By default, the SPI in serial mode. Is there any reason why you want to take the data on the SIMO[1] instead of SIMO[0]. Please refer to your device specific TRM for details on the parallel mode operation. Below is a snippet.

Thanks for your response Charles. I am only testing concepts at the moment. If I could get both SIMO pins to communicate in parallel that would work well too. How would I configure this in Halcogen or how would this be set up in CCS? It looks like I can only get SIMO[0] to transmit.

Hi Robert,
There is no HalCoGen configuration for parallel mode. Neither is there an API provided to configure parallel mode at such. However, you should be able to write to the PMODEx fields in the SPIPMCTRL register to select the number of parallel lines. For SPI1 module, you can only select 2-data line mode. In this case you will write 0x1 to the PMODEx register. Note there are four PMODE fields as the SPI can support 4 different formats.

Hello Charles,

Thank you for your response. I tried to look up some documentation on these registers. Do you have some example code on how to set this?

Thank you
Robert

Hi Robert,

You just write 0x1 to the SPIPMCTRL register like below to set for 2-data line parallel mode.

spiREG1->PMCTRL |= 0x1;

Please be cautious on parallel mode. Does the slave device you are interfacing with supports parallel mode?

Hello Charles,

Yes my slaves supports parallel mode.

In the struct spiBase which spiREG1 is defined I don't have PMCTRL. How did your Halcogen generate a different spiREG1 definition than mine?

See below for my spiBase definition defined from Halcogen:

Hi Robert,

 I was looking at the mibspi, not spi. Aocording to the TRM, the PMODE applies to both the SPI (compatibility mode) and MibSPI modes. 

typedef volatile struct mibspiBase
{
uint32 GCR0; /**< 0x0000: Global Control 0 */
uint32 GCR1; /**< 0x0004: Global Control 1 */
uint32 INT0; /**< 0x0008: Interrupt Register */
uint32 LVL; /**< 0x000C: Interrupt Level */
uint32 FLG; /**< 0x0010: Interrupt flags */
uint32 PC0; /**< 0x0014: Function Pin Enable */
uint32 PC1; /**< 0x0018: Pin Direction */
uint32 PC2; /**< 0x001C: Pin Input Latch */
uint32 PC3; /**< 0x0020: Pin Output Latch */

uint32 PC4; /**< 0x0024: Output Pin Set */
uint32 PC5; /**< 0x0028: Output Pin Clr */
uint32 PC6; /**< 0x002C: Open Drain Output Enable */
uint32 PC7; /**< 0x0030: Pullup/Pulldown Disable */
uint32 PC8; /**< 0x0034: Pullup/Pulldown Selection */
uint32 DAT0; /**< 0x0038: Transmit Data */
uint32 DAT1; /**< 0x003C: Transmit Data with Format and Chip Select */
uint32 BUF; /**< 0x0040: Receive Buffer */
uint32 EMU; /**< 0x0044: Emulation Receive Buffer */
uint32 DELAY; /**< 0x0048: Delays */
uint32 DEF; /**< 0x004C: Default Chip Select */
uint32 FMT0; /**< 0x0050: Data Format 0 */
uint32 FMT1; /**< 0x0054: Data Format 1 */
uint32 FMT2; /**< 0x0058: Data Format 2 */
uint32 FMT3; /**< 0x005C: Data Format 3 */
uint32 INTVECT0; /**< 0x0060: Interrupt Vector 0 */
uint32 INTVECT1; /**< 0x0064: Interrupt Vector 1 */
uint32 SRSEL; /**< 0x0068: Slew Rate Select */
uint32 PMCTRL; /**< 0x006C: Parallel Mode Control */
uint32 MIBSPIE; /**< 0x0070: Multi-buffer Mode Enable */
uint32 TGITENST; /**< 0x0074: TG Interrupt Enable Set */
uint32 TGITENCR; /**< 0x0078: TG Interrupt Enable Clear */
uint32 TGITLVST; /**< 0x007C: Transfer Group Interrupt Level Set */
uint32 TGITLVCR; /**< 0x0080: Transfer Group Interrupt Level Clear */
uint32 TGINTFLG; /**< 0x0084: Transfer Group Interrupt Flag */
uint32 rsvd1[2U]; /**< 0x0088: Reserved */
uint32 TICKCNT; /**< 0x0090: Tick Counter */
uint32 LTGPEND; /**< 0x0090: Last TG End Pointer */
uint32 TGCTRL[16U]; /**< 0x0098 - 0x00D4: Transfer Group Control */
uint32 DMACTRL[8U]; /**< 0x00D8 - 0x00F4: DMA Control */
uint32 DMACOUNT[8U]; /**< 0x00F8 - 0x0114: DMA Count */
uint32 DMACNTLEN; /**< 0x0118 - 0x0114: DMA Control length */
uint32 rsvd2; /**< 0x011C: Reserved */
uint32 UERRCTRL; /**< 0x0120: Multi-buffer RAM Uncorrectable Parity Error Control */
uint32 UERRSTAT; /**< 0x0124: Multi-buffer RAM Uncorrectable Parity Error Status */
uint32 UERRADDRRX; /**< 0x0128: RXRAM Uncorrectable Parity Error Address */
uint32 UERRADDRTX; /**< 0x012C: TXRAM Uncorrectable Parity Error Address */
uint32 RXOVRN_BUF_ADDR; /**< 0x0130: RXRAM Overrun Buffer Address */
uint32 IOLPKTSTCR; /**< 0x0134: IO loopback */
uint32 EXT_PRESCALE1; /**< 0x0138: */
uint32 EXT_PRESCALE2; /**< 0x013C: */
} mibspiBASE_t;

Thanks Charles,

I tried setting up a mibspi instead of spi since the implementation seems easier to have parallel MOSI pins. I see on the scope that now both SIMO[1] and SIMO[0] are transmitting. However the bits aren't what I expect.

I just ran a simple code. In Halcogen I set the transfer group 0 as size 2.

#include "HL_mibspi.h"
void main(void){
uint16 test[2]={0xAAAA,0xFF00};
uint16 response[2]=0;
while(1){
mibspiSetData(mibspiREG1,0,test);
mibspiTransfer(mibspiREG1,0);
while(mibspiIsTransferComplete(mibspiREG1,0)==FALSE);
mibspiGetData(mibspiREG1,0,response);
}
}

Am I missing something in the implementation?

Hi Robert,

  What do you see on the scope? Please refer to the TRM on how the 16-bit data will come out on the two pins. I have shown the screenshot in my earlier reply. If you slave device expects different format/sequence of data to come out from the master then there will be an issue. The TRM describes the supported format. If the format is not compatible with your slave then you cannot use the parallel mode. 

Charles,

For SPI formatting what I am transmitting it directly correlates with the scope measurements. Therefore sending 0xAAAA I will see flipping of 16 bits, sending 0xFF00 I will see a high 8 bits and low of 8 bits. However for mibSPI I do not see this correlation. I do see something. But nothing correlated to the information I actually am try to transmit.

Below is using spiTransmitAndReceiveData. Using the SPI.c functions.

uint16 test1=0xAAAA;
uint16 test2=0xFF00;

spiTransmitAndReceiveData(spiREG2,&config1,1,&test1, &response);
spiTransmitAndReceiveData(spiREG2,&config1,1,&test2, &response);

Below is using mibSPI functions.

uint16 test[2]={0xAAAA,0xFF00};

while(1){
mibspiSetData(mibspiREG1,0,test);
mibspiTransfer(mibspiREG1,0);
while(mibspiIsTransferComplete(mibspiREG1,0)==FALSE);
mibspiGetData(mibspiREG1,0,response);

}

Hi Robert,
I can not understand your scope shot without proper legends. You seem to show only one pin but you are in parallel mode. Please show all signals, i.e. the SPICLK, SIMO[1] and SIMO[0]. What pin is channel 1 in your scopeshot? What pin is channel 2?

Unfortunately at the moment I only have a 2 channel scope available.

The first plot showing the result for the spi functions I measured on pin D1 MIBSPI2SIMO. Here you can clearly see 0xAAAA and 0xFF00 transmitted even without CLK. I expect a similar transmission with mibspi.The second plot showing the results of the mibspi functions I measured on pin E18 MIBSPISIMO[1]. In my transfer group I added 0xAAAA and 0xFF00 however nothing in the scope plot resembles this. My fundamental question is how do I get the first plot with spi to match the second plot with mibspi? Maybe I do not understand the formatting of the mibspi to understand why I am seeing this discrepancy.

Below is a scope capture of both E18 MIBSPI1SIMO[1] (Channel 2 Yellow) and F19 MIBSPI1SIMO[0] (Channel 1 Red)

Below is a screen capture of F19 MIBSPI1SIMO[0] (Channel 1 Red) and F18 MIBSPI1CLK (Channel 2 Yellow)

Thanks Charles. You are correct. I understand how mibspi is implemented now.

Hi Robert,
Glad it is clear to you now!