MSDI

Hello Junsoo,

Can you clarify what you mean when you say you are using two TIC10024 devices?  Can you provide a simple diagram or schematic of how you are connecting the two TIC10024 devices?

Are you trying to monitor the same source (i.e. switch) with two different TIC10024 devices in parallel for a redundant or safety application in case one device fails? 

junsoo kim said:

1. In the case of the /INT pin, it is written that it is allocated as LOW when input is detected from the IN element of MSDI. Is there any other condition that can change the /INT pin to LOW?

The Interrupt INT pin is an active low, open-drain output that asserts when an event is detected in the device including a switch input state change, temperature warning, over-voltage shut down, etc.  These types of interrupt events can be configured in the INT_EN_CFG0 (address 24h) register.

I will note that the INT pin is always asserted LOW after the first detection cycle has completed following the TRIGGER bit getting set.  Could this be what you are seeing?

Regards,

Jonathan

It is used by connecting two int pins (int pins of each TIC10024 device) to one pin C_SWITCH_INT of the MCU.
As you said, I am trying to sense a switch input using two TIC10024s in parallel.

"I will note that the INT pin is always asserted LOW after the first detection cycle has completed following the TRIGGER bit getting set. Could this be what you are seeing?"

The environment I tested is as follows:
Switch input is not implemented in all tests, so it is assumed that there is no switch event.
When the voltage drops to enter the power saving mode of the two-use (parallel) controller, that is, lowpower, the INT pin of the device shows the action of High -> Low -> High.
On the other hand, if only one MSDI is used, the value of the INT pin of the device is maintained as HIGH even if the voltage drops to enter low power.

Due to the operation of High -> Low -> high at the INT pin of the device, the controller judges it as a wake signal, and the power saving mode of the controller is not executed.

The question is:
I want to know how or guide to find out which event caused the device's int pin to go low.
You said "the INT pin is always assigned LOW after the first detection cycle is complete after the TRIGGER bit is set", but I couldn't confirm it when using only one MSDI, but there is a change in the waveform when using two MSDI. Could two parallel connections be a problem? Are there any examples of using this?

I am asking if the INT pin changes even when the first detection cycle starts after the TRIGGER bit is set.

Are the two TIC10024 devices configured with the same settings? 

The INT pin is the logical OR of all interrupt bits and therefore any enabled interrupt event can cause the INT pin to pull low. 

Additionally, the INT pin will always pull low immediately following the TRIGGER bit getting set to "1" to indicate the first cycle has completed and the default High/Low values for the INx pins has been measured.  The INx pins do not have to have changed states to cause the INT pin to pull low.  After this first cycle, any change on the INx level will cause the INT pin to pull low IF interrupt generation has been enabled for that INx channel.  By default, all Interrupt generation events are disabled.

Is your TRIGGER bit set to "1" or "0" for both devices in your test?

Also can you share with me the register configurations for the following Interrupt Enable and Configuration registers?

22h (INT_EN_COMP1)

23h (INT_EN_COMP2)

24h (INT_EN_CFG0)

25h (INT_EN_CFG1)

26h (INT_EN_CFG2)

27h (INT_EN_CFG3)

28h (INT_EN_CFG4)

Regards,

Jonathan

I think you misunderstood the question.
My question is:
After using two MSDIs in parallel, there is a phenomenon where the int pin becomes Low even if all INx are not changed. (using 2 MSDI)
If only one MSDI is used, the INT pin will remain HIGH under the same circumstances. (using 1 MSDI)
From this it is Guessthat the Int pin is affected when using two MSDIs in parallel. Ask if there are any such effects.

INx
Share register settings.

1. first MSDI

22h (INT_EN_COMP1) 0xC5 0xff 0x80 0x06
23h (INT_EN_COMP2) 0xc6 0x7e 0x61 0xe7
WC_CFG0 0xba 0x94 0x49 0x24
WC_CFG1 0xbc 0xd2 0x49 0x45
24h (INT_EN_CFG0) 0xC8 0x00 0x00 0x09
IN_EN 0xB6 0xEF 0xFF 0xFB
THRES_COMP 0xC2 0x00 0x1F 0xFE
INT_STAT 0x04 0x00 0x00 0x00
CONFIG Register.trigger 0xB4 0x00 0x00 0x40

2. second MSDI

22h (INT_EN_COMP1) 0xC4 0x18 0x06 0x78
23h (INT_EN_COMP2) 0xC6 0x00 0x00 0x01
WC_CFG0 0xBA 0x92 0x49 0x24
WC_CFG1 0xBC 0xD2 0x49 0x25
24h (INT_EN_CFG0) 0xC8 0x00 0x00 0x09
IN_EN 0xB7 0xfe 0x3e 0x2c
THRES_COMP 0xC2 0x00 0x1F 0xFE
INT_STAT 0x04 0x00 0x00 0x00
CONFIG Register.trigger 0xB4 0x00 0x00 0x40

The nINT pin is an active-low, open-drain pin that asserts low when an event occurs.  When two devices have the nINT pins connected together in parallel, an event on either device can pull the line low.

The Interrupt Enable Config 0 (INT_EN_CFG0) register can enable the possible events that will cause an interrupt and pull the nINT pin low outside of a couple of other events.  From your configuration, you only have the Switch State Change (SSC) enabled, and the nINT pin should not become active-low if an under/over voltage, temperature warning or shutdown, or parity fail event occurs.

As I have already noted the nINT pin will also become active-low following the completion of the first polling cycle.  Your configuration shows the TRIGGER bit in the CONFIG register is set to 0, so neither device is actively polling.  When you enable the TRIGGER bits for the two devices, both devices will pull the nINT line low.  However, if you have not set either TRIGGER bit, then this is not the reason the nINT line is low.

As explained in the Device Initialization section of the datasheet, the nINT pin will also assert low after the initialization process is complete and following a Power On Reset (POR) event. A device Reset also causes the device to experience a POR event which will cause the nINT pin to be asserted.

Your INT_STAT register does not have any bits set, including the POR bit, so I don't know if you have already read and cleared this register prior to reading it's value to report.  However, the since you don't have any interrupts enable except the switch state change, and you don't have the TRIGGER bits set which is required to monitor the switches for a state change, then the only likely cause for the nINT pin being asserted low is a POR event either from the device initialization or a hardware or software reset event.

Can you tell which device is causing the nINT pin to be asserted low?  You state that when only one is used, the nINT pin stays high all the time.  Can you remove either one of the TIC10024 devices to keep the line high, or is it only one particular device that must be removed in order to keep the line high?

When in the overall power up and device initialization sequence do you see the nINT pin become asserted low?  Monitoring the power supply ramping along with the nINT pins and SPI configuration registers should allow you to see what event occurred just prior to the nINT pin getting set.  This would then point to the possible cause.

Is your MCU issuing a soft reset to the devices through SPI as part of the configuration sequence?  If so, this could also be something to verify.

Regards,

Jonathan

The answer was late.

Looking at the comments above, it seems that you are guessing because of the POR event. Here's what I understood:
1. Does the POR event include that the INT pin is always asserted LOW after the first detection cycle completes after the TRIGGER bit is set?
2. If not 1, low assertion due to controller reset or hardware device reset

The answer to your request is as follows.
1. Please guide me on how to know which device caused the nINT pin to be set low.
2. It is currently not possible to break the parallel connection between TIC10024 units.
3. Since you cannot directly see the register of the device in use, you cannot know when the INT pin is assigned to LOW, and in my development environment, you can only check when the INT pin is dropped using an oscilloscope. At this time, you can also see the switch input, and there is no change value in the switch input.

Yes, the INT pin will be asserted LOW following a POR event as part of the Device Initialization sequence.  This is described in section 8.3.3 of the datasheet.  Both a Hardware and Software Reset will also cause a POR and the INT pin to be asserted LOW as described in sections 8.3.5.2 and 8.3.5.3 of the datasheet.

Also, the INT pin is always asserted LOW after the first detection cycle completes after the TRIGGER bit is set as described in sections 8.4.1 and 8.4.2 of the datasheet.

Other events can be enabled to generate an interrupt and assert the INT pin LOW, but the POR and First Polling Cycle complete following the TRIGGER bit getting set will always occur.

If you are unable to break the parallel connection between the two TIC10024 units, I'm a bit confused about your original post that states your problem doesn't occur when only one device is used.

junsoo kim said:

We are currently using two TIC10024QDCPRQ1 MSDI.
When using two, there is a change in waveform (HIGH -> LOW -> HIGH) as shown below at the INT pin of the device without changing the value of IN0 to IN23.
If only one is used, the value of HIGH is maintained at the INT pin of the device without changing the value of IN0 to IN23.

In order to determine which device is causing the interrupt, you will either need to be able to read the device registers, or break the connection between the two devices or disable one of them.  I see in your schematic that you have test points on the Reset pins for both devices. You could supply voltage to one of the test points that would keep that device in a state of Reset while the other device is allowed to operate as normal.  You could then monitor your system and repeat the process for the other device to understand how each device is operating.

However, in a general sense, the MCU firmware Interrupt Service Routine (ISR) should have the appropriate code to read and clear the TIC10024 registers when the INT pin is asserted LOW.  Because you have two devices sharing a single INT net, you will need to have the MCU read and clear the registers for both TIC10024 devices every time the INT pin is asserted LOW.

Regards,

Jonathan