• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 2 answers
  • Subscribers 32 subscribers
  • Views 1253 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:

DRV8323: strange SPI output

DRV8323: Slow SDO release

Emanuel Kleiber
Prodigy 70 points
Part Number: DRV8323

Hello

I have the same issue: the SDO singal is released by the DRV8323 too slowly. According datasheet max. 30ns, in our case about 600ns.
The SDO has an 4.7k Ohm pullup resistor to 3.3V. The 3.3V is stable, The SDO wire is about 4mm long on the PCB and nothing else is connected to it than the pullupresistor and a 6cm long wire wrap for the oscilloscope probe. I adon't think that the very little soldering flux on the PCB has an impact.
Any Idea why, the SDO is released so slowly?

Thank you and best regards

zoomed in:

  • 0
    TI__Expert 6065 points
    The expert for this part has been notified and will help you tomorrow when he is back in office.
  • 0
    TI__Guru 65450 points
    Emanuel,

    Have you tried a lower value pull-up resistor? Try 1k and let us know how the behavior changes.

    Regards,

    -Adam
  • 0 in reply to Adam Sidelsky
    Prodigy 70 points

    Dear Adam

    Yes, we tried different resistor values: It has an influence of the rising time (of course), but the cause of the problem is not fixed by just decreasing the resistor value. A value of 4.7k to 10k is common in such application. Anyway, the following screenshot is done with a 1.0kOhm pullup resistor, and we are still far away from the specified 30ns.



    I took the second last screenshot of the other thread (DRV8323: strange SPI output) and enlarged it as good as poosible, and you will see that in that case the same problem exists (it doesn't look like 30ns rising time at all):


    Note: Later, we will add other parts to the SPI bus (e.g. EEPROM etc.), and I would like to not go lower than 4.7kOhm for the SDO line. Furthermore in the data sheet there is an example circuit which shows an 10kOhm pullup resistor at the SDO line.

    Regards,
    Emanuel

  • 0 in reply to Emanuel Kleiber
    Prodigy 70 points
    Dear Adam
    So far, our work around is as follows: We implemented two different clock speeds: 1MHz for the DRV8323 and 4MHz for the other normal SPI-Slaves. We switch the clock speed for each communication accordingly. It is not what we like, but the best we can do so far. If you have any advices, please let me know.
  • 0 in reply to Emanuel Kleiber
    TI__Guru 65450 points
    Emanuel,

    The timing here is obviously dependent on your SDO pin parasitics. Is there a way you can reduce the capacitive load on the SDO trace on your PCB?

    Regards,

    -Adam
  • 0 in reply to Adam Sidelsky
    Prodigy 70 points

    Dear Adam,

    "The 3.3V is stable, The SDO wire is about 4mm long on the PCB and nothing else is connected to it than the pullup resistor and a 6cm long wire wrap for the oscilloscope probe."
    --> I don't see much options in improving the measurement nor reducing the capacitive load.

    Note: On our other prototype PCBAs where the SDO trace is not cut off after 4mm (like on the PCBA from above) and is routed on the PCBA to other SPI-Slaves (e.g. EEPROM) with also open collector output, the SDO signal of the other slaves is much much faster (toal lenght of the SDO trace on the PCB is about 5cm). Thus, in my opinion, the slow rising does not depend on the PCB routing etc.

    May you provide a screenshot of the signal on your DRV8323-demoboard where the rising time of the SDO is visible? (namely shorter than 30ns)

    Regards
    Emanuel

  • 0 in reply to Emanuel Kleiber
    TI__Guru 65450 points
    Emanuel,

    I will need to refresh my stock of EVMs, please give me some time to check this.

    Regards,

    -Adam
  • 0 in reply to Emanuel Kleiber
    Intellectual 290 points

    if you use a 3.3v  try this value for the resistor pull up  3.3kohm and try in the DRV 8308 the best is that value...

  • 0 in reply to Adam Sidelsky
    Prodigy 70 points
    Hello Adam,
    Do you have any news?
    Regards, Emanuel
  • 0 in reply to Emanuel Kleiber
    TI__Guru 65450 points
    Emanuel,

    I talked with design and got more info about this spec and issue.

    The spec you are referencing is td_SDO, this is the SDO output data delay time or the time between the SCLK transition and the moment when the SDO data is valid. This is not a rise time guarantee since the pin is an open drain and therefore the rise time is based solely on the external pull up, parasitic capacitance/inductance/resistance.

    Measured on the EVM I am seeing a rise time of less than 100nS.

    Regards,

    -Adam
  • 0 in reply to Adam Sidelsky
    Prodigy 70 points

    Dear Adam

    Thank you for your effort and also the measurement!
    OK, td_SDO is not the rising time ;-)

    On the SDO track there is an additional EEPROM (M95256-WDW) now, thus the DRV8323 and the EEPROM uses the same track on the PCB (total length: 64.1mm). The SDO track is pulled up with 4.7k Ohm to 3.3V. Thus, the EEPROM and the DRV8323 have the exact identical situation/setup. The rising time of the SDO signal is about 600ns, when the DRV8323 is active, and about 10ns when the EEPROM is active. Thus, the slow rising time iis not caused by the PCB or the like.
    In my opinion, the DRV8323 does not release the SDO fast enough. Probably, we have DRV8323s from a "not so good" lot with parasitic capacitance/inductance/resistance as you mentioned (on your eval board, there is an 10k Ohm pullup and you measure a 6x faster rising time). So this problem may not exist in the future anymore.

    Our work around now, is to use a normal speed (4MHz) to communicate with EEPROM (and later also a display), and a ultra slow speed (0.5MHz) with the DRV8323 for initialisation and fault read out.

    OK, so the topic can be closed, even the issue is not solved.

    Best regards
    Emanuel