• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 33 subscribers
  • Views 107 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.

Original question:

TCAN4551-Q1: SPI communication problem (SPIERR)

TCAN4551-Q1: SPI errors on transactions after reset from SLEEP mode.

Ed Goldstein
Prodigy 90 points

Part Number: TCAN4551-Q1

Hi, 

I have been working on a driver for the TCAN4551.

I have an intitalisation sequence that raises the RST pin for a few ms then lowers it. After that, the datasheet says it takes at least 700us before SPI communication can begin. My function waits 2ms to be safe. It then reads the device ID, and also writes to and reads from the scratchpad in order to verify the SPI communication.

If I run this sequence after powering on the device, all works correctly. if I run this sequence when the device is in SLEEP mode, then I get an SPI error signalled in the first byte clocked out of the scratchpad read. So I do receive the device ID, but probably the scratchpad write had a problem.

If I instead wait 3ms after I return the RST line low, I don't get the SPI error problem.

The datasheet says the minimum time should be 700us. Is there a reason why I have to wait for so long for the SPI to stabilise? Does this suggest a hardware design problem on my board? Why is the behaviour different between when I power on the TCAN4551 and when it has just been in SLEEP mode?

Thanks in advance.

Ed.

  • 0
    TI__Mastermind 35670 points

    Hi Ed,

    Does the power supply on the VIO pin remain ON while the TCAN4551 is in Sleep Mode?

    What type of clock are you using on the OSC1/2 pins?  Is it a crystal or a single-ended CMOS clock?

    The 700us minimum time requirement comes from the amount of time the internal LDO's need to turn on and stabilize.  The clock/crystal also needs to be stable in order for the digital core to be able to respond to any SPI read/write transactions.  If you are using a crystal, it may take more than 2ms to start oscillating which may be the reason it fails after only a 2ms wait delay but works after a 3ms wait delay.

    Regards,

    Jonathan

  • 0
    Prodigy 90 points

    Hi Jonathan, thanks for the quick reply. 

    It maybe that the SLEEP mode is a red herring. It looks like these errors can happen after powerup, so not just sleep mode.

    VIO is 3.3v and is on for the whole time. Yes, it's a 40MHz crystal.

    I don't know if our board designer went through the crystal application note or real measurements, but our implementation looks roughly ok.

    ...

    You have explained that the 700us is independent of the crystal stabilization time. I see tCRYSTAL is shown on Figure 14. Power Up Timing but not on Figure 20. Timing for RST Pin in Normal and Standby Modes. Even if I place a breakpoint/delay immediately before lowering the RST, it doesn't make a difference. Only the delay after lowering the RST makes a difference. This would suggest that the cry stabilisation time starts after RST goes low, and perhaps should have been shown on Figure 20. Timing for RST Pin in Normal and Standby Modes.

    Either way, it seems like our HW is probably ok, and we will just have to wait the few ms.

  • +1 in reply to Ed Goldstein
    TI__Mastermind 35670 points

    Hi Ed,

    The device reset is implemented by causing a device POR event.  Toggling the RST pin high will result in the internal main core LDO to be disabled.  Once RST is released the LDOs will be re-enabled and the device will power up to the default values.  

    The reset event will also stop the clock/crystal and therefore it may need to start oscillating again and this time may vary by crystal type and the amount of load capacitance in your circuit.  So similar behavior is expected for initial power-on or a reset event.

    Regards,

    Jonathan