TMS320F28335: Triple-buffered reception of the McBSP interface is not working because the RRDY flag does not signal the second stored SPI character in the triple buffer

Matthias,

I've asked a colleague to look into this, can you take a look at this post https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1049305/tms320f28388d-mcbsp-rrdy-flag-not-set-as-i-expect/3933434#3933434 and see if this is describing the same issue you are observing?

Best,

Matthew

Matthew,

Thanks for the fast reply!

Yes, it seems to be the same issues! But I don't like the answer that there is no workaround for this behavior.

That means I can't use the triple-buffer for receiving data because I never knows how long and where my transmission function is delayed/interrupted because of an interrupt or higher priority task.

So I always have to wait for the received character before I send the next character. This leads to gaps on the SPI bus with around 30% performance loss.

I'm wondering why the triple-buffer is implemented when it is not properly working.

Maybe you have another idea to work around this issue.

Thanks and regards,

Matthias

Hi Matthias,

Matthias Wauer said:

Maybe you have another idea to work around this issue.

I will send a note to our design team to see if there is any other possible workaround that can be implemented for this instead of waiting for the received character before having to send the next character. I will update you as soon as I hear back.

Best Regards,

Marlyn

Hi Matthias,

Matthias Wauer said:

So I always have to wait for the received character before I send the next character.

I verified with the design team, and unfortunately the only other workaround other than waiting for the received character before sending the next character is to read RFULL (receiver full bit) to indicate if there are 3 received words. 

We plan to publish something in our documentation to highlight this issue.  

Best Regards,

Marlyn

Hi Marlyn,

Thanks for the clarification!

Best Regards,

Matthias

Hi Marlyn,

The workaround with waiting for RFULL is somehow not working for me.

I've tried the following:

    /* activate the loop back mode */
    McbspaRegs.SPCR1.bit.DLB = 1U;

    /* wait for the transmitter to be ready for the first character */
    while (0U == McbspaRegs.SPCR2.bit.XRDY);
    /* write first 16-bit to transmit buffer */
    McbspaRegs.DXR1.all = 0x1122U;

    /* wait for the transmitter to be ready for the second character */
    while (0U == McbspaRegs.SPCR2.bit.XRDY);
    /* write second 16-bit to transmit buffer */
    McbspaRegs.DXR1.all = 0x3344U;
    
    /* wait for the transmitter to be ready for the third character */
    while (0U == McbspaRegs.SPCR2.bit.XRDY);
    /* write second 16-bit to transmit buffer */
    McbspaRegs.DXR1.all = 0x4455U;

    /* wait until RFULL flag is set (all three characters received) */
    while (0U == McbspaRegs.SPCR1.bit.RFULL);
    charRx_u16 = McbspaRegs.DRR1.all; /* 0x1122 is read (RRDY and RFULL go to 0 and stay there) */
    charRx_u16 = McbspaRegs.DRR1.all; /* 0x3344 is read */
    charRx_u16 = McbspaRegs.DRR1.all; /* 0x3344 is read again instead of 0x5566 !!! */

It seems that the third transmitted character got lost.

Best regards,

Matthias

Hi Matthias,

Thank you for the update. I will replicate this on my side to see if I get the same results. I will reply back tomorrow with an update from my side.

Best Regards,

Marlyn

Hi Matthias,

I am able to duplicate what you are seeing. I need to communicate again with our design team. I will respond early next week with an update. Thank you for your patience.

Best Regards,

Marlyn

Hi Matthias,

I apologize for the delay, but I have heard back from our design team and the RFULL workaround cannot be used in this case as there are issues with that feature as well, like you noted. I will work on documenting this so that it is clear to others using the McBSP. 

Best Regards,

Marlyn