BQ79758-Q1: Question about the status of NFAULT pin

Hey Chase, 

Please let me know if you have any further questions here or if the problem has been resolved. 

Hope you're having a good day, 

Arnold Venter

Dear Arnold,

Thank you for your support.

1. The screenshot below is the register value when UV is occurred. Please check that these values are right or not.

2. If the device is going to sleep, TSREF and DVDD are both goes to low.

Do you know the way of DVDD remains high even device is go to sleep by register setting?

Best regards,

Chase

Hey Chase, 

The fault register readings suggest that the device is detecting the faults. According to the datasheet (BQ79718 Datasheet page 111), the DVDD should remain high when the device goes to sleep. Are you sure that the customer is not shutting the device off? Please verify or send to me the instruction the customer is using to make the device go to sleep. Also, please let me know if the customer is using an EVM or a custom PCB. 

Please conduct the following steps: 

1. wake device and autoaddress

2. set voltage readings to within the desired ovuv range

3. enable ovuv detection

4. reset faults

5. go to sleep (verify dvdd stays high)

6. inject ovuv fault by changing cell voltage to be outside the threshold (both above and below -- this will ensure that both ov and uv get triggered)

7. set voltage readings back to within the desired ovuv range

8. wake devices and autoaddress

9. read faults and verify that both uv and ov are active

Please let me know how this experiment goes and if you need any further help. 

Hope you're having a good one, 

Arnold Venter

Any updates from your end Chase? 

Dear Arnold,

Thank you for your support.

Customer followed the step which you mentioned.

There was okay until step #4. But in step #5, if the device goes to sleep, DVDD goes to low.

I attach the code of my customer. Could you check it and give me the way of DVDD not goes to low even device goes to sleep?

Best regards,

Chase

Dear Arnold,

Thank you for your support.

Please let me know if there is an update.

Best regards,

Chase

Dear Arnold,

Please let me know if there is an update.

Best regards,

Chase

Hello Chase,

Apologies for the delay in response I missed the notification of your response until now. Could you tell me what the value of CONTROL1_GOTO_SLEEP_POS? It is possible that a go to shutdown may be being sent. 

Hope this helps, 

Arnold Venter

Dear Arnold,

Thank you for your support.

CONTROL1_GOTO_SLEEP_POS is 0x02.

Customer uses bq7971x_reg.h header file which TI provided. They did not change anything.

Do you expect the reason of this problem?

Best regards,

Chase

Hey Chase, 

I wanted to check that in case the code was written by the customer if the CONTROL1_GOTO_SLEEP_POS was actually 0x03. In this case, it would have caused the device to shutdown. 

As a quick aside, a ring topology is needed to detect faults if there are multiple devices -- I misread the datasheet before -- but this should not affect the customer. 

Could you perform the following steps for me: 

1. wake device and autoaddress

2. set voltage readings to within the desired ovuv range

3. disable adc readings (section 6.3.5.1.1 says to ovuv and adc readings should not occur at the same time)

4. set desired pin voltage to a value inside the ovuv range

5. enable ovuv detection

6. read DEV_STAT[OVUV_RUN] to verify that the protectors are runing

7. reset faults

8. read ovuv fault readings (verify they are 0 since your voltage readings should be in range)

9. go to sleep

10. nFault should not be triggered here

Could you provide me the logic analyzer files from these steps, keeping track of the uart line and the dvdd line? 

Then, could you describe how the customer is injecting the fault uv fault? 

Dear Arnold,

Thank you for your support.

I will let you know the result of the test you mentioned once the test is done.

And my customer did some test, Please give me some advice about it.

- Measured NFAULT/GPIO2 (P53)

1) In case of normal status

2) In case of UV(Under Voltage) status - NFAULT pin is unstable, neither high nor low.

I think NFAULT should be stable low under UV situation.

Could you give me advice about case 2?

Best regards,

Chase

Hey Chase, 

Thank you for sending these over. I think I understand the waveforms but just to check -- what is the context of these waveforms? Are these captures of nFault in a system where commands are executed cyclically? It seems that in case 1 there are also faults being detected which causes nFault to drop and then faults are being reset. Could you give me more information about what communication is being sent to the device / what commands are being sent and what faults are being introduced and also when those faults are getting cleared? 

Regarding test case 2, those results are very feasible depending on the customer's procedure. If faults are getting cleared, it does make sense for nFault to only fall occasionally. If the customer is using round robin mode, Section 6.3.5.1.2.1 of the datasheet explains how ovuv checks are performed and that the time between cyclic is approximately tOVUV_CYCLE_ACT_MULTI, or ~70ms according to page 15 of the datasheet. If the customer is using single mode, this also makes sense since ovuv would not be continuously running. Additionally, fi the device is in sleep mode during the customer's cycle, then the ovuv cycle has a different delay. 

Hope this helps, 

Arnold Venter

Hey Chase, 

Any updates? 

Arnold