TMS570LS3137: SPI complete flag one byte too early

Andy Worsley89

Part Number: TMS570LS3137
Other Parts Discussed in Thread: HALCOGEN,

Hi. I'm using a TMS570LS3137 HDK board to send and receive SPI messages. I have created a small variation of the HalCoGen generated spiTransmitAndReceiveData function. It is identical to the original except that it uses 8 bit source and destination arrays. I'm seeing some strange behaviour. The code sits in a loop whilst waiting for the Rx complete flag to be true. However this function exits one byte before the transmission is complete. I have attached a scope trace. I set a port pin high when the function is called and low again after it returns.

Can anyone explain why it's doing this and how I get around it?

Thanks

Andy

over 5 years ago

0 Miro over 5 years ago

TI__Mastermind 21425 points

Hello,

Please, attach your code if possible.

0 Andy Worsley89 over 5 years ago in reply to Miro

Intellectual 670 points

Hello,

The halcogen configuration for the message is for 8 bit data and the function I am using is a shown below.

uint32_t spiTxAndRx8BitData(spiBASE_t *spi, spiDAT1_t *dataconfig_t, uint32 blocksize, uint8_t * srcbuff, uint8_t * destbuff)
{
    uint16 Tx_Data;
    uint32 Chip_Select_Hold = (dataconfig_t->CS_HOLD) ? 0x10000000U : 0U;
    uint32 WDelay = (dataconfig_t->WDEL) ? 0x04000000U : 0U;
    SPIDATAFMT_t DataFormat = dataconfig_t->DFSEL;
    uint8 ChipSelect = dataconfig_t->CSNR;

    while(blocksize != 0U)
    {
        if((spi->FLG & 0x000000FFU) != 0U)
        {
           break;
        }

        if(blocksize == 1U)
        {
           Chip_Select_Hold = 0U;
        }
        /*SAFETYMCUSW 45 D MR:21.1 <APPROVED> "Valid non NULL input parameters are only allowed in this driver" */
        Tx_Data = *srcbuff;

        spi->DAT1 =((uint32)DataFormat << 24U) |
                   ((uint32)ChipSelect << 16U) |
                   (WDelay)           |
                   (Chip_Select_Hold) |
                   (uint32)Tx_Data;
        /*SAFETYMCUSW 567 S MR:17.1,17.4 <APPROVED> "Pointer increment needed" */
        srcbuff++;
        /*SAFETYMCUSW 28 D MR:NA <APPROVED> "Hardware status bit read check" */
        while((spi->FLG & 0x00000100U) != 0x00000100U)
        {
        } /* Wait */
        /*SAFETYMCUSW 45 D MR:21.1 <APPROVED> "Valid non NULL input parameters are only allowed in this driver" */
        *destbuff = (uint8_t)spi->BUF;
        /*SAFETYMCUSW 567 S MR:17.1,17.4 <APPROVED> "Pointer increment needed" */
        destbuff++;

        blocksize--;
    }

    return (spi->FLG & 0xFFU);
}

You will notice that the only difference between this function (apart from the identifier) is that the tx and rx buffers are 8 bit.

The main loop then has

gioSetBit( hetPORT1, 17, 1 );

spiTxAndRx8BitData( spiREG2, (spiDAT1_t *)&DataFmt_12V, REG_RD_SIZE, TxBuffer, GrpBResults );

gioSetBit( hetPORT1, 17, 0 );

You would expect the clock to finish sending data before the port pin goes low, but from the screenshot you can see that is not the case.

0 Miro over 5 years ago in reply to Andy Worsley89

TI__Mastermind 21425 points

Hello,

I made a test with copy/paste your code in my program and everything is as expected.

My setup is with SIMO/SOMI shortened with wire.

0 Andy Worsley89 over 5 years ago in reply to Miro

Intellectual 670 points

That's bizarre. I tried it again and I get the same results as you. So, who knows what happened there? Maybe some quirk of a USB scope.

Arm-based microcontrollers

Arm-based microcontrollers forum

TMS570LS3137: SPI complete flag one byte too early