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.
I believe the HALCoGen 04.04.00 MibSPI driver generated for the TMS570LS21x family contains a bug in the mibspiInit() function. In the buffer RAM initialization block, the CSHOLD bit in the last buffer of a transfer group is always set to 0, even when the chip select hold setting is enabled for that group. I expected the initialization code to match what is produced by HALCoGen 04.02.00 for the TMS570LS20x family when the chip select hold setting is enabled.
Jose,
This is done on purpose.
At the end of the transfer, the chip select has to be release high. That is the reason why on the last buffer the bit is cleared.
Here's the HALCoGen graphic. The CSHOLD tooltip text is correct per the code generated with 04.02.00 for the TMS570LS20x family. However, the tooltip is no longer correct based on your response. I see no benefit in this selection affecting the individual buffers prior to the last in the transfer group.
Jose,
Here is an extract from the TRM:
So for me the message displayed in Halcogen is misleading. I will communicate this to the team for a fix in the next release.
Concerning your problem, there is no direct way on MIBSPI to chain multiple transfer group.
In your case, this is done if I understand via the DMA.
I will discuss the possibility to have a new check box to force keeping CS active at the end of a full transfer.
Thanks for your input.
Hi Jose,
Yes tool tip is misleading. I have raised a CQ ticket to HALCoGen team to address this. Also requested them to add options to choose CSHOLD at Buffer level and at TG level.
2 Workaround that I can propose.:
Workaround 1:
After MIBSPIU Init you can go and set the CSHOLD bit of the last buffer ( BUFF_ID) of each Transfer Group that you do not want the CS to be deactivated after it finishes.. Like below code snippet.
For MIBSPI1
mibspiRAM1->tx[BUFF_ID].control = mibspiRAM1->tx[BUFF_ID].control | (uint16)((uint16)1U << 12U) /* chip select hold */
For MIBSPI3
mibspiRAM3->tx[BUFF_ID].control = mibspiRAM3->tx[BUFF_ID].control | (uint16)((uint16)1U << 12U) /* chip select hold */
For MIBSPI5
mibspiRAM5->tx[BUFF_ID].control = mibspiRAM5->tx[BUFF_ID].control | (uint16)((uint16)1U << 12U) /* chip select hold */
Workaround 2:
Go to MIBSPI Init, you can see the 8 Transfer Groups configuration, ( Below is one transfer group configuration).. In the Red Highlighted line I have changed 0 to 1, you could also do it so that CSHOLD is Applied for last buffer in the TG too. Note: Every time you regenerate in HALCoGen this goes back to 0. Once your mibspi configurations are frozen, you can copy mibspi.c and rename to some other file like mibspi_custom.c and include in the project and exclude mibspi.c
#if (8U > 0U)
{
while (i < (8U-1U))
{
mibspiRAM1->tx[i].control = (uint16)((uint16)4U << 13U) /* buffer mode */
| (uint16)((uint16)1U << 12U) /* chip select hold */
| (uint16)((uint16)0U << 10U) /* enable WDELAY */
| (uint16)((uint16)0U << 11U) /* lock transmission */
| (uint16)((uint16)0U << 8U) /* data format */
/*SAFETYMCUSW 334 S MR:10.5 <APPROVED> "LDRA Tool issue" */
| ((uint16)(~((uint16)0xFFU ^ (uint16)CS_0)) & (uint16)0x00FFU); /* chip select */
i++;
}
mibspiRAM1->tx[i].control = (uint16)((uint16)4U << 13U) /* buffer mode */
| (uint16)((uint16)1U<< 12U) /* chip select hold must be zero for last buffer */
| (uint16)((uint16)0U << 10U) /* enable WDELAY */
| (uint16)((uint16)0U << 8U) /* data format */
/*SAFETYMCUSW 334 S MR:10.5 <APPROVED> "LDRA Tool issue" */
| ((uint16)(~((uint16)0xFFU ^ (uint16)CS_0)) & (uint16)0x00FFU); /* chip select */
i++;
}
#endif