FDC1004: Using the reset functionality

Hi Clancy,

Thank you for your quick response.
I will try to readback all the registers but I think it will work because I already read back the ID register when I read a 0 for the measurement to check if the chip is still connected. And I do readback the correct value (0x1004).

Or do you want to know if all registers are returned to their reset value? Anyway I will try to get all register values.

Can you maybe give an answer to my last question as well?

Thanks again!

Best,

Bart

Hi Clancy,

I read back the values from all registers when I read a 0 from the measure register, below is the list:

As can be seen, I have 2 registers that are still as I set them for my application but the register FDC_CONF is also set but is readback as 0.

The manual says: "The offset calibration register is reloaded by the default value at power-on or after reset." So from this line I can conclude that the chip did not reset because my offset has not been changed.

Please let me know if I can do more testing.

Thanks again.

Bart

Bart,

I agree with you; it looks like the device is not accidentally being reset. Is it possible that your MCU code is accidentally re-writing the FDC_CONF REPEAT bit to 0?

Would it be possible to disconnect the I2C lines after the initial configuration and monitor the CINx signals with an oscilloscope to see if the same issue occurs?

Hi Clancy,

Thanks again for the response. 
Unfortunately it is not possible to disconnect the I2C lines because, as I explained in my first post,  we move a metal probe towards a fluid level. If I can't read back the I2C values I cannot stop the moving probe. Also if I can not read via I2C lines I don't know if the issue occurs.

I have a workaround now. As I saw from the registers above, the FDC_CONF is readback as 0, I write the FDC_CONF register to 0x0980 (continue measurement 1, 200 sps) whenever I read 0x0000 from the measurement 1 register. But this takes extra time which is definitely not preferable and can cause other functionality to be delayed.

Can you still tell me why there is a reset option at all in this chip?

Do you want me to explain more how and when I send settings to this device?

I can't comment too much about why we included a software reset option in the chip. It's probably a useful feature for the tests that TI runs. In most applications, I don't see a need for it.

Are you able to attach oscilloscope leads to the input signal (CINx)? Could you set it up for a normal trigger and also capture the I2C signals? If you normal trigger, then you should be able to catch the last measurement. In particular, we would be looking at the I2C communication immediately before and after this occurs.

I have some log files of the I2C bus. I was not able to connect a scope to the CINx pins. But what information can it give us if would be able to do so?

Below is a logging of a wrong measurement.

Below is log of a correct measurement

To give you an idea of the frequency, this happened after 560 measurements/ level detections. I can run 150 level detections per hour.
I hope the loggings will help define the issue.

Thanks again!

With the way you are doing the measurements, probing CINx would not be useful. Originally, I thought you said that this issue occurred even when not reconfiguring the device before a measurement. If that was the case, then monitoring CINx could tell us exactly when the measurement fails, and we could see if there were any issues with the I2C signals immediately beforehand.

Can you add a step to check that the RST bit in the FDC_CONF (0x0C) register goes back to 0 to ensure that the reset has completed before sending the next I2C write transaction? This would happen immediately after the I2C write of 0C 89 80.

Have you solved the problem yet? Were you able to try my suggested experiment?

Hi Clancy,

I am sorry for my late answer, I was on holiday the last 2 weeks.
I tested this already before I started this topic but I will check it again and I will see if I can add some logging to check if this is requested correctly.

Thanks for your advise.

Hi Clancy,

I tested again today and it does not matter if I wait for the reset bit to go to 0 again.
The issue is just as frequent then when I would not wait for the bit to change.

I will do some more testing but I hope you have some more suggestions.

thanks