• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 63 subscribers
  • Views 79 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TPS92518HV: SPI Protocol Not Per Datasheet

TI-CSC
Genius 10755 points
Part Number: TPS92518HV

Tool/software:

Hello E2E Experts,

Good day.

We have a PCB similar to the TPS9518HV evaluation board. A PIC16F1827 MCU supervises 2 TPS9518's for a total of 4 LED channels powered from a 48V supply. Although the PIC can successfully read/write registers in the TPS9518, I find that for the read/write response frames the SPE flag is continuously set. Even after reading the STATUS/FAULT register, the SPE flag remains continuously set. I have created a test program to do read/write/readback on the ThermWarnLimit register over a range of values from 0 to 255.

The test program performs the following steps:

for (i=0; i<256; i++) {

Read Status register

Write 'i' to the ThermWarnLimit register  

Read Status register (to clear faults?)

Read ThermWarnLimit register

Compare data field of ThermWarnLimit read to i

This program runs successfully and does not report any faults but the read/write response frames still have SPE set.

Regards,

TI-CSC

  • 0
    TI__Mastermind 19935 points

    Hello,

    We need to see logic analyzer traces for SPI transmissions to see what is happening.  Your code might not be doing what you think.  

  • 0 in reply to fhoude
    TI__Genius 10755 points

    Hello Fhoude,

    Good day.

    Attached herein is the logic analyzer traces for SPI transmissions.

    SPI Errors.pdf

    Thank you in advance.

    Regards,

    TI-CSC

  • 0 in reply to TI-CSC
    TI__Prodigy 610 points

    Hello TI-CSC, thank you for attaching the trace data. Having looked at the trace it appears to me that the issue is with the 16 bit transfer that is performed in order to get the device SPI result from the previous command. The command 0x0000 is not a valid command. A valid read of register 0x00 is achieved by sending 0x0200 on the SPI bus. Try issuing a valid device command after the initial command in order to view the result. You can do this in your situation by issuing the same command 2x or sending the command followed by a valid register read. Be sure that parity is getting set correctly!