SPI Communication Issue with OA TC6 SPI Protoco

[malove]

Hello,

I am implementing SPI communication between the S32K314 MCU and MAC-PHY (LAN8651).

For Control Transaction Read (where the master reads a register value from the slave), the process follows the OA TC6 SPI protocol as shown in the image below:

The S32K314 MCU has a maximum SPI frame width of 64 bits. However, in some transactions, the required frame length exceeds 64 bits.

For example, as shown in the image below, when performing a Protected Write, the frame consists of:

• Control Header (32 bits)
• Protected Write Data (64 bits)
• Total: 96 bits

After measuring the waveform, I noticed that if the SPI frame exceeds the configured bit width in the LPSPI Configurator, the SCK clock stops and then resumes for the remaining bits.

My Questions:

1. Is there a way to send more than 64 bits in a single SPI transaction, or at least reduce the delay between frames?
2. If the SCK stops and then resumes to complete the transmission, would this cause any issues with the communication?

[malove]

Anyone help me?

[RomanVR]

Hello @malove 

I apologize for the delayed response. Below are the answers to your questions:

The maximum frame size is 64 bits, as it is designed to be AUTOSAR 4.7 compliant, according to the "Specification of SPI Handler/Driver" documentation provided by AUTOSAR. However, you can split the data into smaller frames and reduce the delay between frames by adjusting the timing parameters, which are outlined in the image below and described in Table 441 of Chapter 70 in the S32K3XX Reference Manual Rev. 9:

If the previous transmission has ended and another transmission is initiated to send the remaining bytes of the complete data frame, there should be no communication issues, as long as the SCK continues to run during transmission.

Please let me know if this information is helpful or if you have any further questions.

- RomanVR.

[malove]

Hello, @RomanVR 

Thank you for your response.

I have an additional question regarding SPI communication.

I want to transmit a total of 96 bits (32-bit + 32-bit + 32-bit).
Currently, if I set the FrameSize to 32 bits, the CS (Chip Select) remains LOW while sending three 32-bit frames sequentially.
However, in this case, the SCK stops after each 32-bit transfer before resuming, which is causing an issue.

From your response, I understand that if FrameSize is set to 64 bits, I can send 64 bits + 32 bits in two separate transfers.
But my goal is to transmit all 96 bits continuously without any interruption in SCK (Continuous Transfer).

Is there a way to achieve this, ensuring that SCK does not stop between frames during the transmission of 96 bits?
Would enabling TCR[CONT] or TCR[CONTC] help in solving this issue?

I appreciate your insights.

Thank you.

[RomanVR]

Hi @malove 

Your understanding of the frame size is correct, however the frame size is limited by hardware as shown in the image below. Therefore, it is not possible to transmit an only frame of 96 bits.

Also, the registers in continuous transfer mode are also limited by the maximum frame size as mentioned in chapter 70 of the S32K3XX Reference Manual Rev. 9 (registers CONT, CONTC).

Please let me know if this information was helpful.

- RomanVR.

[malove]

Hello, @RomanVR 

Thank you once again for your kind response.

I understood your answer as "It is not possible to specify a Frame Size exceeding 64 bits."

However, as shown in the image below, enabling the "SPI Enable Large Frame Size" function allows the generation of a Frame Size exceeding 64 bits.

- From top to bottom: SCK, CS, MISO, MOSI.

If the Frame Size is set to 64 bits, the output appears as follows:

In this case, 64 bits are output, and a gap occurs in between. This seems slightly different from what you described. How should I interpret this?

Thank you.

Best regards,

[RomanVR · Accepted solution]

Hello @malove 

I apologize for the confusion, I assumed that you were using SPI with MCAL layer, but with IP you can configure a transmission for a data width > 64 bits just as you have shown for the 128 bit transmission. 

About the gap you are observing in the clock signal when configuring the frame size of 64 bits, I assume you are transmitting more than 64 bits. If that’s the case the gap is caused because of the differences between the frame size and the data size. Since you are transmitting more information, once the first frame is sent, a second transmission for the remaining bytes is initiated; as a second frame is sent, the SCK goes low before being active again.

Please let me know if this answers your question and if you have more doubts.

- RomanVR.