TMS570LC4357: Help with the Auto-Generated Halcogen API -spiTransmitAndReceiveData

Varikoti SIva DK

We are working on a project which requires SPI communication and as such to meet the data communication protocol as specified in the datasheet we are referring, we may need to change the auto- generated APIs.

And so, we needed some material or insights to refer to, to do the same.

Some of our questions:

1) Is CS_HOLD same as CS for SPI communication? (We had this doubt because on the forum we saw a code initializing CS_HOLD to FALSE, and after in the if statement inside the while loop, we are again making CS_HOLD to 0)

2) What is Chip_Select_Hold? (active low/ active high)

2) What is the task of WDEL (some delay factor we are assuming) and CSNR ?

And lastly if we were to modify this particular API to transmit the data first and then only start receiving, how should we proceed? (Currently we are making use of a combination of spiTransmitData and spiReceiveData)

uint32 spiTransmitAndReceiveData(spiBASE_t *spi, spiDAT1_t *dataconfig_t, uint32 blocksize, uint16 * srcbuff, uint16 * 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;

/* USER CODE BEGIN (14) */
/* USER CODE END */
    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 = (uint16)spi->BUF;
        /*SAFETYMCUSW 567 S MR:17.1,17.4 <APPROVED> "Pointer increment needed" */
        destbuff++;

        blocksize--;
    }

/* USER CODE BEGIN (15) */
/* USER CODE END */

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

over 2 years ago

0 jagadish gundavarapu over 2 years ago

TI__Guru* 76526 points

Hi Varikoti siva,

We started working on your issue and will provide an update soon.

Thanks & regards,
Jagadish.

0 jagadish gundavarapu over 2 years ago in reply to jagadish gundavarapu

TI__Guru* 76526 points

Hi Varikoti Siva,

Varikoti SIva DK said:
1) Is CS_HOLD same as CS for SPI communication? (We had this doubt because on the forum we saw a code initializing CS_HOLD to FALSE, and after in the if statement inside the while loop, we are again making CS_HOLD to 0)

2) What is Chip_Select_Hold? (active low/ active high)

The CS_HOLD is not same as CS, i mean the value of CS_HOLD not directly controls the CS value. Instead of this CS_HOLD value helpful to hold the chip select signal to be activated in between transfers. I mean, in general the CS signal will get deactivated in between transfers right, but if CS_HOLD bit set then the CS_HOLD signal will not get deactivated in between transfers.

This behavior is required because, some slave devices require the chip select signal to be held continuously active during several consecutive data word transfers. So, this CS_HOLD will be helpful to work with such kind of slave devices.

If you verify the above waveform, first we wrote CS_HOLD =1 right, it means that the CS signal should not deactivated after completion of first transfer. That is why you can see the CS pin is in hold state only after completion of the first transfer. And on second wrote, we made CS_HOLD =0 right, so that means after completion of second transfer the CS signal should need to be deactivated, so you can see that after end of second transfer the CS signal goes to logic high (i.e. deactivated).

For more details refer 28.2.6.5.2 Hold Chip-Select Active and 28.2.6.5.2.1 CSHOLD Bit in Master Mode sections in TRM.

Varikoti SIva DK said:
2) What is the task of WDEL (some delay factor we are assuming) and CSNR ?

As we discussed in above paragraph, in general the CS pin will get deactivated in between the transfers right. The actual deactivated time between the transfers is min of 2VCLK cycles. But some slaves might require more deactivation time, in that case you can control that deactivation time using WDEL and WDELAY values.

where,

WDEL- is a enable bit for WDELAY

WDELAY- holds the actual delay value in terms of VCLK cycles.

The delay formula is

The chip select deactivation delay (Wait delay) = (WDELAY + 2) × VCLK_Period duration

So, for example if i configure WDELAY=5 and i enabled WDEL bit then the min chip select deactivation time would be equal to the 7 VCLK periods.

For more details refer WDEL and WDELAY bits description in registers description section.

Thanks & regards,
Jagadish.

Arm-based microcontrollers

Arm-based microcontrollers forum

TMS570LC4357: Help with the Auto-Generated Halcogen API -spiTransmitAndReceiveData