• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 31 subscribers
  • Views 1629 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS570LS1224: CS_HOLD function in MibSPI slave operation

user3559954
Prodigy 30 points
Part Number: TMS570LS1224
Other Parts Discussed in Thread: HALCOGEN

Hello,

I'm trying to setup MiBSPI in following configuration:

  • TMS570 is a slave device on SPI bus, word length is 8-bit
  • MiB SPI is configured to use 8 buffers, 0-7, with CS[0] selecting the device
  • Each time buffer 7 is written to, DMA copies received content to buffer in SRAM
  • Because I don't know the number of bytes transmitted during single CS-active event, I've enabled "Chip Select Hold" in HALCoGen

I'm now testing the case where 16 bytes are transmitted to TMS570 with CS being constantly active during transmission. In this case the RxRAM will receive 8 bytes in 8 buffers, DMA will be triggered once, and the rest of traffic is lost.

I've inspected the code generated by HALCoGen (v04.05.02) and found following line for buffer 7:

mibspiRAM3->tx[i].control = (uint16)((uint16)4U << 13U)  /* buffer mode */
                          | (uint16)((uint16)0U << 12U) /* chip select hold must be zero for last buffer */

When I manually change CS_HOLD to 1 for buffer 7, I get the expected behavior - two DMA triggers and all of sent data being copied to SRAM.

Why is CS_HOLD set to 0 in generated code? Why does comment say "chip select hold must be zero for last buffer"?

Thanks

Josip

  • 0
    TI__Guru 59540 points
    Hello User,

    I am currently looking into your post and will get back with you soon. If, through your own debug, you are able to resolve or have new questions, please let me know.
  • 0
    TI__Guru 59540 points
    Hello Josip,

    CS_HOLD is only relevant if the device is in SPI Master mode. It is not considered in Slave Mode.
  • 0 in reply to Chuck Davenport
    Prodigy 30 points

    Hello Chuck,

    I found documentation to be very incomplete and sometimes contradicting itself. This is particularly  frustrating aspect of dealing with this component.

    In description of CS_HOLD flag in TXRAM, it is indeed marked as irrelevant for slave mode. Yet, there is a sub-chapter named "28.2.11.2 The CSHOLD Bit in Slave Mode (Multi-buffered Mode)" that specifies different behavior of MibSPI depending on value of this flag.

    I was also able to confirm the difference it makes in slave mode in my experiments, as I note in first post.

    Please take another look at this issue.

    Thanks

    Josip

  • 0 in reply to user3559954
    TI__Guru 59540 points

    Hello Josip,

    I think that the confusion comes from different behavior if the mode of operation is in buffered mode or compatibility mode. In compatibility mode the CSHOLD value is ignored/unused but in MibSPI mode has meaning and will change the behavior relative to the state of the CS signal. Certainly I would encourage you to use the document feedback links within the document to submit issues such as you have described relative to conflicting or confusing information.

    In regard to the issue at hand. When you configured your transfer group within Halcogen did you check both of the boxes for CSHOLD as shown in the picture below?

    The behavior for the checkbox to the right is that CS is held even after the last buffer is transmitted. So, in slave mode, maybe this translates into removing the code writing CSHOLD as 0 for buffer 7. Can you try this and get back with me?

  • 0 in reply to Chuck Davenport
    Prodigy 30 points

    Hello Chuck,

    I've reported few errors I noticed so far. I hope corrections will find their way into new revision quickly so other engineers don't have to spend as much effort on same issues.

    I enabled the checkbox you mentioned. The generated code now looks like this:

    mibspiRAM3->tx[i].control = (uint16)((uint16)4U << 13U)  /* buffer mode */
                          | (uint16)((uint16)1U << 12U) /* chip select hold must be zero for last buffer */ 
           (...)

    This code works well in my case, but notice that the comment still contradicts the value that is set. Please file this issue to be corrected in HALCoGen (and maybe also the incomplete label on the checkbox in GUI).

    Thanks for your help in this matter.

    Josip

  • 0 in reply to user3559954
    TI__Guru 59540 points
    Hello Josip,

    Thanks for the feedback. I know there are some revision updates in progress at the moment so hopefully all that you have reported will be included. If you want, feel free to summarize and send to me in the messaging section of the E2E and I will make sure they are brought to the documentation owner's attention. Also note that I have copied the HalCoGen SW lead on this thread so that they can be aware of the comments and issues surrounding CSHOLD configuration.
  • 0 in reply to Chuck Davenport
    TI__Genius 14205 points

    Hi

    Bug ID SDOCM00122903 Raised to Fix the Misleading Commnets in HALCoGen.

    Fix will be rolled out in upcoming release.