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.

TIC12400-Q1: Can't read registers

Part Number: TIC12400-Q1
Other Parts Discussed in Thread: TIC12400

Tool/software:

Hello,

I have a board with TIC12400-Q1 and esp32-wroom

The schematic:



Like datasheet, i have pull-up's in /INT and CS_n
24V in VS and 3.3v in VDD

So, i make a simple script in micropython, try to read the device ID:

from machine import Pin, SPI
import time


PIN_CS = 5
PIN_RESET = 21

cs = Pin(PIN_CS, Pin.OUT, value=1) #starts with CS_N HIGH
reset = Pin(PIN_RESET, Pin.OUT, value=0) #starts with reset LOW

spi = SPI(2,baudrate=100_000, polarity=0, phase=1, bits=8, firstbit=SPI.MSB, sck=Pin(18), mosi=Pin(23), miso=Pin(19))


print("Init TIC")
time.sleep_ms(15) #15ms before reset
reset.value(1) # put RESET in HIGH before transmit
time.sleep_ms(1) # wait 6ms before starts transmission

# read decive ID
tx = bytearray([0x02, 0x00, 0x00, 0x00]) #32bit with 0x01 add
rx = bytearray(4)

cs.value(0) #put CS_n in LOW, to start transmission
time.sleep_ms(1) #waits 1ms before start transmission
spi.write_readinto(tx, rx) #start transmission
time.sleep_us(1) #wait 1ms before ends transmission
cs.value(1) # put CS_n in HIGH to end transmission

# show RX
device_id = (rx[1] << 8) | rx[2] #collect data from reply RX MOSI

print("TX =", ["0x%02X" % b for b in tx]) #show TX data
print("RX =", ["0x%02X" % b for b in rx]) #show RX data
print("Device ID = 0x%04X" % device_id) #show DEVICE ID



In osciloscope, I have this signals:


blue: CS_n
yellow: RESET

-----

blue: CS_n
yellow: SCLK

-------

blue: CS_n

yellow: MISO (SO)

blue: SLCK

yellow: MISO (SO)


The MOSI pin never chages the state, is allways in LOW. Allways LOW in osciloscope.

I already try 3 different boards with new TIC12400, and is the same behaviour in all.

Is possible to have some support? The design is good, and the code is allright?


  • Hello Jose,

    We are looking into this and will respond by tomorrow. Thank you!

    Regards,

    Josh

  • Hello,

    Thanks for the help.

    I still haven't been able to solve the problem. If you can help, I'd appreciate it.

    Regards,

    Jose 

  • Hello Jose,

    Apologies for the delay. Last couple of delays were very hectic so I didn't have time to answer your question.

    Will provide an answer by tomorrow. Thank you for your patience.

    Regards,

    Josh

  • Hello Jose,

    The screenshot below comes from a logic analyzer and shows Device ID reading. I am sending [0x02 0x00 0x00 0x00] without the parity bit since the TIC supports odd parity only.

    1) In your first waveform, I see your reset going High. For this exercise, could we maintain the reset pin low? 

    2) Is it possible to have all signals (MOSI, MISO, CS, CLK) all in one scope shot? This would help with the debugging

    3) Can you probe Vs and Vdd to make sure those pins actually read 24V and 3.3V, respectively? 

    Regards,

    Josh

  • hello Josh,

    thanks for help.

    I can't put the 4 signals in same scope. I maintain the same trigger and record the signals

    24V and 3.3V (measured in TIC pins)

    I put RESET to GND (LOW), and have this results:

    CLK (blue) and CS_n (yellow)

    CLK (blue) and MOSI (yellow)

    CLK (blue) and MISO (yellow)

    MOSI (blue) and MISO (yellow)



    I try to arrange 4 signals in same alignment view



    the output result is:

    TX = ['0x02', '0x00', '0x00', '0x00']
    RX = ['0x80', '0x00', '0x00', '0x41']
    Device ID = 0x0000

    so, if I change the Phase to "0" in SPI, I obtain this:

    TX = ['0x02', '0x00', '0x00', '0x00']
    RX = ['0xC0', '0x00', '0x00', '0x00']
    Device ID = 0x0000

  • Hi José,

    We are still looking into this question and will provide a response soon.

    Regards,

    Jack

  • Hello Mr Jack,

    I apreciate your help.

    I think this IC is the best choice for my automotive hardware development, but I’m in a hurry to complete the troubleshooting and confirm that this IC will work as expected.

    I need to know whether I should keep using this IC or move forward to other options.

    If you can help me find the problem, I would greatly appreciate it.

    Is very dificult to find information about TIC12400-Q1 outside of TI doccumentation. 

    My best regards,

    José

  • Hello Jose,

    We are will provide an answer today. Thank you for your patience.

    Regards,

    Josh

  • Hello Jose,

    Looking at the MISO waveform, the device ID is 20h. The data is latched on the falling edge and not the rising.

    Also, it seems you are getting a Parity Fail flag in the MISO signal. Nothing stands out to me other than CS signal not returning to a High state when 32 clock cycles are completed.

    From what I'm seeing the part is able to receive and send SPI signals.

    As a sanity check, can you do the following:

    • Read IN_EN (1Bh) register
    • Write 0xFFFFFFFF to IN_EN
    • Read IN_EN register again

    Once you read IN_EN for the second time, you should see all 1s in that register. This is a quick test to see that nothing is wrong with the SPI communications

    Regards,

    Josh

  • Hello Mr Josh,

    Thanks for your help.

    I connect RESET to GND, and with the same inicial code (change to Phase=0), I try to read the device ID, and obtain this:



    Result:

    Init TIC
    TX = ['0x02', '0x00', '0x00', '0x00']
    RX = ['0xC0', '0x00', '0x00', '0x20']
    Device ID = 0x20

    So, I saw that if I disconnect osciloscope probe from MOSI, the MISO pin reads ("C0 00 00 00"). If I connect osciloscope probe to the SI pin, the MISO pin reads "C0 00 00 20". 

    the CS_n returns to High, after aprox 100uS.



    I obtain 0x20 for device ID, and I assume that is OK.




  • Hello Jose,

    Since the first data returned reads 0xC0, that means a POR and SPI_FAIL have been detected. 

    The POR flag is normal since this occurs when the part starts up. This can be cleared by reading INT_STAT.

    However, the SPI_FAIL relates to the 32-bit clock cycle. Can you read INT_STAT and see if the 0xC0 is cleared?

    I would also recommend you do the sanity check I mentioned in my previous comment. But so far everything looks good.

    Regards,

    Josh