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.

HALCoGen 04.04.00 MibSPI bug with TMS570LS2124

Other Parts Discussed in Thread: HALCOGEN

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.

  • True, unless disabled transfer groups are being used in order to insert padding bytes between transfers.

    In my case, I have a daisy chain of three sensors connected to the processor's SPI bus. Each sensor returns 24-bits of (unsigned) data. The daisy chain acts like a shift register, so I read 12 bytes from the first sensor in order to read 3 bytes from each sensor (4 x 3 = 12).

    Using HALCoGen, I have configured the MibSPI peripheral to have 8 1-byte transfer groups. TG0, TG2, TG4 and TG6 have a length of 1 and are disabled. TG1, TG3, TG5 and TG7 have a length of 3 and are triggered on the falling edge of NHET10. I then configured the DMA engine to move data from the MibSPI RX RAM into memory for later processing when RX buffer 15 receives new data. Finally, the CSHOLD bits for TG1, TG3 and TG5 were set to 1 so the chip select is not deactivated during the 12 byte SPI transfer.

    Having the interleaved disabled transfer groups, effectively transforms 24-bit sensor samples into 32-bit values, which makes configuration of the DMA engine very straightforward.

    If HALCoGen is going to generate code such that the chip select at the end of every transfer group is deactivated, the transmit buffers graphic on the HALCoGen MibSPIx Transfer Groups tab should be changed. The graphic leads people to believe the chip select hold selection, like the enable WDELAY selection, is only for the final buffer in the transfer group.

    I now believe I cannot use HALCoGen for my MibSPI configuration needs. As is, I would need to change to having 1 1-byte transfer group with a length of 12 and reconfigure my DMA engine to account for the elimination of padding bytes. May I propose the chip select hold selection in HALCoGen be something that can be set on a per buffer basis?
  • 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