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.

TRF7962A: SPI Interface Timing

Part Number: TRF7962A

Hi All,

Please tell me about SPI Interface Timing of TRF7962A.

Customer is conducting 4-wire SPI communication with external MCU.

In Datasheet(slos757f) P32 6.12.6.2, "MOSI data changes on the falling edge, and is validated in the reader on the rising edge, as shown in Figure 6-17".

However, there was a case where it was impossible to write to the Register of TRF7962A by Timing of change at this time.

Is there timing information from the falling edge of SCLK until MOSI Data changes?

Attached file is contents tested by changing Timing.

Question about TRF7962A.xlsx

Best Regards,

Takashi

  • Hello Takashi-san,

    Page 10 of datasheet specifies that both MOSI data setup and MOSI data hold time needs to be 15ns minimum. The hold time means that it must hold 15ns after clock rising edge until data is guaranteed to be clocked in. That is the requirement for MOSI data changing, and it has nothing to do with the falling edge of SCLK.

    What speed SPI Clock are they using?

    Also have they consulted this document? http://www.ti.com/lit/an/sloa140a/sloa140a.pdf

  • Hi Ralph san,

    Thank you for your reply.

    Setup, and hold time are described in "2.Communication Waveform" of the attached waveform.

    tSU SI, tHD SI = 240ns.

    SCLK is operating at about 2.08 MHz with tLO, tHI = 240 ns.

    Although Errata is introduced, I confirm it just in case.

    Best Regards,

    Takashi,

  • Hello Ralph-san,

    Is there any data that is necessary other than the value of tSU SI, tHD SI(240ns) added and SCLK 2.08MHz?

    They are keeping the Minimum 15 ns of MOSI Data, but is there anything else that can not be written to the register of TRF7962A at this Timing?

    tSU, SI = 240 ns, tLO, tHI = 240 ns, there is a part where the falling edge of SCLK and the timing change of MOSI DATA overlap.

    Is there any possibility that this timing affects Register writing?

    (Writing to Register has been successful / failed before and after this Timing)

    Best Regards,

    Takashi

  • Hello Takashi-san,

    At the moment I don't have any other data regarding this, but it is an open issue on our end currently. I should be able to provide more information tomorrow.
  • Hello Takashi-san,

    We have not been able to re-create this issue with our test bench setup (MSP430 based) as it lacks the ability to finely control the SPI data in a manner where I can force the reported timings to occur. Therefore I cannot conclude one way or another if there is an issue at this moment. We will investigate this further in coming months but as that requires significant changes to our system setup for such tests (this sort of issue has not come up before...). I don't have a timeline to provide when we will be able to schedule in those efforts.

    A clearly identified workaround is to configure the SPI bus so that the falling edge of MOSI occurs after the falling edge of SCLK. Please have the customer implement that workaround.
  • Ralph-san,

    Thank you for your comment. Sorry for the late reply.

    I want to confirm it just in case.

    > A clearly identified workaround is to configure the SPI bus so that the falling edge of MOSI occurs after the falling edge of SCLK.

    > Please have the customer implement that workaround.

    The falling edge of MOSI "before" falling edge of SCLK, it look like STOP Condition.

    Would you say that the contents commented as Workaround is to avoid the STOP Condition?

    Even if CS is Enable, does communication stop when a STOP condition occurs?

    The customer communicates using "SPI with Slave Select".

    Best Regards,

    Takashi

  • Hello Ralph-san,

    Is my recognition correct?

    I'm sorry I have asked you many times.

    Best Regards,

    Takashi

  • Hello Takashi-san,

    I cannot confirm that the workaround is specifically to avoid STOP condition. We do not have full understanding of the issue as we have not been able to replicate it on our end. As a workaround has been identified, this has become a low priority issue and will not be investigated until 3Q18 to uncover further details.
  • Hello Ralph-san,

    Thanks for your comment.

    I am sorry, please let me check another one.

    Is the workaround taught valid for both "SPI without Slave Select" and "SPI with slave Select"?

    Best Regards,
    Takashi

  • Hello Takashi-san,

    The question doesn't make sense to me. If the thought is that the workaround is to prevent the STOP condition from triggering on SPI w/ SS, why would it even be relevant for SPI without SS? Then you wouldn't execute a proper STOP...
  • Hello Ralph-san,

    Thanks for your comment. I'm sorry Ican not explain well.

    What I wanted to check is that the STOP Condition is valid in "SPI with Slave Select"?

    In Datasheet, I was concerned that there was not much description about STOP Condition with the waveform of SPI with SS.

    Best Regards,

    Takashi

  • Hello Takashi-san,

    Takashi Ritsuo said:
    What I wanted to check is that the STOP Condition is valid in "SPI with Slave Select"?

    Again as I've said before, I cannot confirm if that is what is occurring. Until the investigation later this year, I cannot confirm nor deny if the STOP condition is occurring for that case.