OPT3001-Q1: Sensor CRF is 0 after power up

Hi Daniel,

So it looks like after powering the device on, you are then putting the device in continuous conversion mode and then polling the CRF bit until the conversion is ready?

[Curly] Yes.

Is the issue here that when you start the conversion, the CRF is always 0, indicating that the device is not taking any measurements?

[Curly] Once the CRF is 0, I'll not request the result register.

What is the correct setup here?Once you start the conversion, how often are you checking the CRF bit? 

[Curly] Power up > I2C initial > set configure register as above I mentioned > reading CRF every 25ms > if CRF is set, reading the result register.

Are you checking the CRF constantly until the first conversion is complete and the CRF = 1? 

[Curly] Yes.

Thanks,

Curly

Hi Curly,

How long are you reading the CRF bit before it results in a failure? Are you reading the bit for a determined amount of time, or are you allowing the device to run continuously and seeing that the bit never goes high at all? If you are setting a time limit, what is this time?

Also, is this occurring on multiple devices or is this all on the same device? Are you reading the output registers as well to confirm that the device did a successful conversion?

Thanks,
Daniel Balmaceda

Hi Daniel,

I polling the CRF bit every 25ms, the conversion time was set to 100ms, sensor should return CRF bit 1 every 4 times by reading CRF bit.

This issue occurs on multiple device with power on/off several times.

Once the CRF is 0, I'll not read the result resgiter.

Thanks,

Curly

Hi Daniel,

This is Dilbert from Garmin platform software division.

Nice to meet you.

We've some waveform that show odd timing as below.

According to the above waveform, we found that after 0x44 slave address sent, there is a time gap which keeps 42ms low then just send 1st byte data out.

Could you tell me in what situation ALS pull SCL to low for 42ms? [Notice]: the issue happened after that.

BTW, we also would like to know the power on timing after power on that is when could host send first command to ALS after power on?

Because we're afraid that host sent command so early that ALS isn't able to work.

Thanks a lot.

Dilbert Kuo

Hi Daniel,

Sorry for late reply.

Daniel Balmaceda said:

Just to clarify here, the above issue with the CRF bit not coming high occurs after the behavior described in your post?

[Dilbert] Yes.

Daniel Balmaceda said:

Regarding your test setup, is the OPT3001-Q1 the only device connected on the bus? If so, could it be possible that some other device is pulling the bus low?

[Dilbert] There is no other device on the bus, only ALS and host on the i2c bus.

Daniel Balmaceda said:

Also, have you increased the time between power on and when you start communication with the device to verify whether or not its an issue with the power on timing?

[Dilbert] In below waveform, orange signal indicates power, yellow signal indicates SCL signal. As you see, after power on, the first command is sent after 306ms. I think the time slot should be enough for ALS internal initialization.

Is there any situation in which it makes ALS pull SCL low?

Thanks a lot.

Dilbert Kuo

Hi Daniel,

Sorry for late reply due to another urgent issue needing to be handled.

Daniel Balmaceda said:

Are you able to write the configuration and then read from the device after the line is released?

YES

Daniel Balmaceda said:

Are all units having this same behavior? Does this occur every single time this device is powered on or is this a one time instance? Could you provide a percent estimate of how often this occurs?

The failure rate is around 10%, and as shown in the picture below, the issue occurs when only the I2C clock (CLK) is pulled low. We also used a logic analyzer (LA) to monitor the I2C, as shown below.

Normal device power on:

Failed device power on:

LA record failed device:

Now, we found a recovery mechanism, when we observed ALS always return CRF 0, we try to resend the conversion mode command. After that ALS will be able to work normally.

Do you have any idea why resend the conversion mode command can resolve this issue?

Thanks a lot.

Dilbert Kuo

Hi Dilbert, 

No worries, let me run this through the design team to see what could possibly be causing this issue on the SCL. I would not expect this line to be pulled low after power on.

Thanks,

Daniel