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: Register Cofiguration for 24V Switching Signals Detection

Part Number: TIC12400-Q1

Dear manager

         Recently, we applied the chip of TIC12400-Q1 in our vehicle contol unit board.  We have got in a trouble. We need your help in the field of resgister configuration.

         We use this chip to detect switching signals with the level of 24V.

         We set the registers as following steps:

               (1) set TRIGGER = 0  ( Register: CONFIG , Command: 0xB4000001 ) ;  

               (2) enable 24 channels ( Register: IN_EN, Command: 0xB7FFFFFE );

               (3) set comparator threhold to 4V( Register: THRES_COMP, Command  0xC2001FFE );

               (4) set wetting current in each channel to 15mA and set each channel in the mode of wetting current auto-sacaling ( Register: WC_CFG0, Command  0xBB6DB6DA;  Register: WC_CFG1, Command  0xBC2DB6DA);

               (5) set IN0 ~ IN9 channels in CSI mode( Register: CS_SELECT, Command  0xB80007FF);

               (6) set each channel in the comparator mode ( Register: Mode, Command  0xE4000001 );

               (7) set TRIGGER = 1 to start the chip ( Register: CONFIG , Command: 0xB4001000) ;

         However, after sending the Command in step (7), we find the chip is reset and the POR =1.  We confirm that :

               (a) the Comand sent in the first 6 steps are well done, and the corresponding registers are well set;

               (b) during sending the Command in step (7), we have kept the electrical level in the RESET pin as low level to avoid hardware reset,  and we have not sent reset Command through SPI communication.

         When we did not execute the command in step (2), namely, did not enable 24 channels (we also have tried to enable only 1 channel), the TRIGGER = 1 can be well set, and the chip did not enter the reset mode.

         

  • Hi Haiming,


    You mention "you have not sent reset command through SPI communication". Have you placed a scope on the RESET pin to ensure that nothing has caused the state to change? Can you provide any protocol analyzer images to show that you are sending the correct bytes via SPI and are not accidentally sending the reset command?

  • Haiming,

    We haven't heard from you in a while so we will assume your issue was resolved. I will mark this issue as closed but if you have additional questions you may reply here to re open the thread or start a new one.

    Thank you,
    Adam