LDC1312: No output from the coil a few hours later after power on

Kawasaki-san,

Thank you for reaching out on E2E.  An ABA swap is a good idea.  It would be beneficial to do this fully, by swapping the suspect device into a system that is known to be good while also swapping in the unit from the good system to the one that has failed and testing both. We want to see if the failure follows the device, or the system, or in some cases might be resolved through re-soldering a weak connection.

It would be good to try and capture voltages at VDD and SD during power up as well as checking that the OSC is running as expected.

I would also recommend doing a full register read.  I assume the device is behaving as you described even after the first write based on your description, but it is good to check that registers are being written correctly.  It would also be good to capture any information from the status and error registers to provide insight. 

Thanks,

Scott

Kawasaki-san,

Also due to the end of year Holidays, I will not be available to support you next week, but we will have other experts available probably after Thursday or Friday who will be able to provide more insight based on any findings from the tests above.

Thanks,

Scott

Hello Scott-san,

Thank you for your comments.  My customer sent me the plots of CLKIN first, but those didn't show any issues.  I'm asking to take plots of VDD and SD as well as full register read as you suggested.  I'll share the plots and ABA swap check results when I get those from them.  If you need more to find the root cause, please let me know.

Best Regards,

Yoshikazu Kawasaki

Kawasaki-san, 

In addition to the tests Scott mentioned, I have a few more questions/tests to help gather information about this issue. I would put priority on the ABA swap, but some of these may be able to be answered in parallel: 

• Is the timing of the failure consistent or random? 
• Can they decrease RCOUNT to see if the failure occurs more frequently with a higher sample rate? 
• Can they provide steady state oscilloscope captures of the sensor channels when the device is in a proper working state? 
• You mention the issue can be reproduced after power cycles. Just to clarify, does the device operate normally for a period of time after the power cycle before going back into the issue or does it immediately go into the issue if power cycled after it occurs? 

Thank you, 

Justin Beigel

Hello Scott-san, Justin-san,

Thank you very much for your comments even during the seasonal vacations.  We had year-end & new year vacations until yesterday, so my replay was delayed.  I'm sorry about that, but I got some updates from my customer.  As Scott-san asked, they took plots of VDD and SD pins as well as register read, but I don't think those show any issues.  I'll ask them to work on the items I got from Justin-san next.  Please tell me if you find any issues from the results shown below or additional suggestions from the previous Justin-san's suggestions.

The OFFSETx and STATUS registers are different between after power on and after the issue happens.  My customer understands the OFFSETx registers will change depending on the DATA0/1 to make those to the target value(0x0100), so the OFFSETx registers became maximum(0x7FFF) which should be the correct behavior for LDC1312.  No data updates were done on channels 4 and 5 with the issue.

Best Regards,

Yoshikazu Kawasaki

Kawasaki-san, 

I don't see any issues with those additional plots. In addition to the tests I suggested, can you have them change the ERROR_CONFIG register to 0xF8FF and share the output of the data registers and status register during good and problem states? This will enable all error reporting and may be helpful for us to debug the issue. 

Best Regards, 

Justin Beigel

Hello Justin-san,

Thank you very much for your comments again.  They're trying to do ABA swap test, so I'll inform you once I get results from them.

• Is the timing of the failure consistent or random? 

-> They said random.  The issue sometimes happens around 1 hour later after power cycle, but it sometimes does around 4 or 5 hours later.

• Can they decrease RCOUNT to see if the failure occurs more frequently with a higher sample rate? 

-> They'll do this later.

• Can they provide steady state oscilloscope captures of the sensor channels when the device is in a proper working state? 

-> Is this OK for you?  The channel 5 also works well like the channel 4 during the normal operation, but it stops working a few hours later after power cycle.

• You mention the issue can be reproduced after power cycles. Just to clarify, does the device operate normally for a period of time after the power cycle before going back into the issue or does it immediately go into the issue if power cycled after it occurs? 

-> It works well for a while(a few hours) after power cycle.

• can you have them change the ERROR_CONFIG register to 0xF8FF and share the output of the data registers and status register during good and problem states?

-> They'll do this later.

Best Regards,

Yoshikazu Kawasaki

Kawasaki-san, 

Thank you for the oscilloscope captures. In addition to those, can they provide a capture while both channels are working properly? Let us know when they have more information from their ABA swap or other tests. 

Best Regards, 

Justin Beigel

Hello Justin-san,

I only have plots just after power on which are included in the file I posted first, but would you like to see the ones while both channels are working well before the issue happens?  They said both worked well before the issue happens though.

Best Regards,

Yoshikazu Kawasaki

Kawasaki-san, 

I would like to see the steady-state portion of the waveforms for both channels before the issue occurs. I want to see how the sine wave settles and what the amplitude of their signal is before the issue occurs. It isn't the highest priority item for this issue but would be nice to collect if they can while working on other tests. 

Thank you, 

Justin Beigel

Hello Justin-san,

They took register dump and waveforms before/after the issue by changing the ERROR_CONFIG=0xF8FF(actually 0xF8FD since ERROR_CONFIG[1]=reserved).  Would you please tell me if you find anything?

- Register dump

- Waveforms

Best Regards,

Yoshikazu Kawasaki

Kawasaki-san, 

Thank you for the plots and register dump. I suspect that decreasing the RCOUNT setting will also decrease the amount of time it takes for this error to occur if it helps in there testing. 

Is there any update on the ABA testing they are performing? 

Thank you, 

Justin Beigel

Hello Justin-san,

Thank you for your continuous support.  I understand you see no issue so far.

I also suppose the RCOUNT value would increase/decrease the time for this issue to occur.  I'll tell you once I get the results.

There is no information yet for ABA swap.  I'll tell you once I get it.

Best Regards,

Yoshikazu Kawasaki

Hello Justin-san,

I hear they didn't see issues frequently even if they decreased the RCOUNT value.  It takes a few hours anyway, so they might not be able to recognize the time until the issue occurs.

Best Regards,

Yoshikazu Kawasaki

Kawasaki-san, 

Thanks for having them check the RCOUNT setting. Are they still in the process of performing the ABA swap? 

Also, at the beginning of this thread, you mentioned they only had a few samples with this issues. Do they have an exact number of devices they experienced this issue on? 

Thank you, 
Justin Beigel

Hello Justin-san,

We got intermediate results of the ABA swap test.  They replaced the unit with the issue to a good one and found the issue doesn't occur even after 72 hours.  Therefore they think the issue depends on the unit.  They'll replace a good unit to the one with the issue later to confirm the complete ABA swap.

We're asking how many units they have the issue now.

Best Regards,

Yoshikazu Kawasaki

Hello Justin-san,

I got the exact number of units with the issue.  It is increasing and 9 out of 1778 now.  It isn't always the same channel with the issue.  The LTC was the same(2CUA2HY), but there are 4 LTCs now.

Best Regards,

Yoshikazu Kawasaki

Kawasaki-san, 

Thanks for the additional information. Let me know when they complete the rest of the ABA swap and based on those results, we will go from there. 

Best Regards,
Justin Beigel

Hello Justin-san,

We got the result of the rest of the ABA swap test.  They replaced the unit on the good board with the unit having the issue and found the issue occurred.  The board with the issue replaced by a good unit still works well.  Therefore it was confirmed the issue depends on the unit.  The following shows the summary of ABA swap tests.  What would you suggest next?

Best Regards,

Yoshikazu Kawasaki

Kawasaki-san,

Thank you for the update.

Justin is out-of-office today and will return tomorrow.

We will look into the possible next steps and update this thread by COB on Wednesday.

Regards,
John

Hello John-san,

Thank you for your comments.  I'll wait for Justin-san's suggestions, but the number of the units with the issue is increasing and it is 10 now which was 9 last week.  Do you think my customer can do anything to fix this issue by some registers or something?  Or do you think the issue is caused by the failure units and they can't fix this issue?  Please give me your comments for this as well.

Best Regards,

Yoshikazu Kawasaki

Kawasaki-san, 

Based on the information, I would expect that the customer could put the device into sleep mode via bit 13 of the CONFIG register and then back into active mode to clear the issue. This would act like power cycling the device but i don't think it would prevent the issue from occurring again. 

For the devices that are experiencing this issue, I would recommend returning those units to us: https://www.ti.com/support-quality/additional-information/customer-returns.html. This will allow us to look at the devices experiencing this issue in more detail. 

Best Regards, 
Justin

Hello Justin-san,

Thank you for your comments again.  We're the current distributor for the customer,  but those samples were purchased from another distributor who had been assigned previously, so the samples would be returned to you by the distributor as the recommended action shown in the URL you suggested.  Please let me close this thread unless I get more questions from the customer.

Best Regards,

Yoshikazu Kawasaki

Hi Justin-san,

Thank you for your support.

I'd like to talk about this issue in private messages.
I requested a friend ship.
Please confirm it.

I'd like to confirm the problem with the circuit. or layout 

BR,
Kengo.

Hello Kengo, 

I have accepted the request. Feel free to share more information with me directly in the private messages. I am going to mark this thread as closed for now while we have the side conversation but we can reopen this up if needed in the future. 

Best Regards, 

Justin 

Hello Justin-san,

As you would suppose, the issue hasn't been fixed yet since you just have accepted the FA request, so they still have the issue from several units.  Therefore I got additional questions.  They'd like to implement a workaround to enter sleep mode once and return to normal mode to prevent the issue.  Would you please give me your comments for the followings?

1. Have you found the potential root cause of the issue?  If yes, would you please tell me how my customer would be able to fix this issue?

2. Do you think RESET_DEV(0x1C[15])=1 will act as same as entering sleep mode once and returning to normal mode?  Or CONFIG[13] you mentioned is the only bit to act as same as entering sleep mode once?

3. How long would it need to configure the workaround from the previous workaround?  I mean how long wait time would they need to have between the workarounds?

Best Regards,

Yoshikazu Kawasaki

Hello, 

Unfortunately, we do not have a root cause for this issue yet. Any updates from our end on the FA request should be sent directly over email. 

For the RESET_DEV bit, this will reset all the device registers to their default which will put the device into sleep mode in the process. Either way will work, but using the RESET_DEV will mean you have to reconfigure the device registers afterwards. Using the RESET_DEV and configuring the device will take a bit more time than just putting it into sleep and waking it back up. 

As for how often they would need to perform a sleep or reset on the device, its hard to say. You mentioned that it takes a few hours for the issue to appear for them so anytime less than that should help but at this time, there is no guarantee the issue wouldn't appear sooner for them. If they are able to, they could put a software check to see if the data/status registers from one of the devices is stuck and then perform the sleep/reset only after the issue is detected. Is this something that would be possible for them? 

Best Regards, 

Justin 

Hello Justin-san,

Thank you very much for your comments.

> Unfortunately, we do not have a root cause for this issue yet.

Were you able to reproduce the issue then?  If not, do you need anything to reproduce the issue?

> perform the sleep/reset only after the issue is detected.

They'd like to avoid the issue to occur, so they don't want to enter sleep mode after the issue is detected, but do before that.

Best Regards,

Yoshikazu Kawasaki

Hello, 

Do you know the FQE contact that was assigned to the FA request? If so, I can reach out to them to check on the status of the returned units. 

Best Regards, 

Justin 

Hello Justin-san,

I don't know about it since it was done by another distributor who had supported the customer when the samples were sold.  Would you please check it in your side?

It seems my customer has started replacement of LDC1312 unless the workaround will be found soon.  Do you have any suggestion for that?

Best Regards,

Yosh8ikazu Kawasaki

Hello,

I was able to find the FA request in our system. It looks like the QA team completed their analysis and has sent a response back already. The end result is that the QA team found no evidence of failure with the device.

As for work around, this isn't a normal behavior of the device and we haven't seen this issue in testing units we have in the lab. With that being said, I can't guarantee a timing for resetting the device preemptively on the few devices exhibiting this behavior since that is an unknown factor.

Best Regards, 

Justin 

Hello Justin-san,

Which one would you choose if you were the customer?  I don't think anyone would go with #2 though.

1. Continuous use of LDC1312 with a potential workaround by toggling SLEEP_MODE_EN bit often.

2. Replacing LDC1312 with LDC1612 since both of them are pin-to-pin compatible.

3. Replacing LDC1312 with LDC3114 since the architecture is different and the issue shouldn't occur on LDC3114.

4. Others(if you do this, please tell me the suggestion and the reason why you do)

Best Regards,

Yoshikazu Kawasaki

Hello Yoshikazu, 

The issue seen on the LDC1312 in this thread is not something we have replicated here. With that being said, we can't guarantee a timing to prevent the issue with option 1 because we wouldn't expect this to be necessary for normal operation of this device. Replacing the device with either LDC1612 or LDC3114 would depend on their preferences between the two devices. Neither have exhibited this behavior before.

You mentioned they want to prevent this issue from occurring rather than reacting to it if it happens again, but would it be possible to react on a first time occurrence of this issue? For example, have a software check for the issue and then if it does occur start a recurring reset operation for that unit.

Best Regards, 

Justin

Hello Justin-san,

Thank you for your comments again.

As you may know from the files I uploaded, INTB stays high even when the issue occurs, so their system doesn't know when it does from the INTB pin.  If it becomes INTB=low, I agree with you that their software checks the issue and reacts by INTB=low.

The differences of the registers when it does are 0x00(DATA0), 0x02'(DATA1) and 0x18(STATUS).  Therefore their system needs to monitor those registers to detect the issue.  Their system needs to toggle SLEEP_MODE_EN bit after detecting the issue anyway.  It means I suppose their system should enter sleep mode and return to normal mode by toggling SLEEP_MODE_EN bit rather than monitoring the 0x00, 0x02 and 0x18 registers before toggling SLEEP_MODE_EN bit.  What do you think they should do?

Best Regards,

Yoshikazu Kawasaki

Hello Yoshikazu, 

Under normal operation, are they using the INTB to interrupt their microcontroller to read data from the LDC1312? I saw in the configuration previously shared that the INTB was enabled in the CONFIG register but the ERR_CONFIG register wasn't set to report anything on INTB. If they are using INTB to report DRDY, INTB should trigger for the DRDY bit on consistent timing related to the RCOUNT setting used.

Would it be possible to have a timer compare to check for INTB latching high for too long? For example: 

Best Regards, 

Justin Beigel