Is there any correlation between lpcomp detection and adc?

HI,

We are producing products using the nRF52832. During production, a defect occurred where the lpcomp detection voltage was operating at a voltage lower than the design voltage.

This defect occurs in approximately 5% of devices.

This issue has occurred before, and I've asked two questions, but none have been resolved.

Please refer to the previous question below for the circuit diagram and source code.

- Question 1)   When detecting low battery voltage using LPCOMP and ADC, the detection voltage changes (occurs approximately 5%) 

- Question 2)  The reference voltage setting of lpcom does not match the calculation 

I finally found a solution to a problem that kept occurring in small numbers during production.

Previously, if lpcomp was detected at "1)", the ADC for "2)" would be performed.

However, on the PCB where the lpcomp issue occurred, detecting lpcomp at "1)" and always performing ADC at "2)" allowed normal operation.

1) Read lpcomp.

nrf_lpcomp_task_trigger(NRF_LPCOMP_TASK_START);
nrf_lpcomp_task_trigger(NRF_LPCOMP_TASK_SAMPLE);
nrf_lpcomp_result_get_temp = nrf_lpcomp_result_get();

2) Stop lpcomp, process ADC once, and start again.

nrf_drv_lpcomp_disable();
temp_bat = BatVoltage();
nrf_drv_lpcomp_enable();

int32_t BatVoltage( void )
{
    int32_t BAT_output = 0;
    uint8_t channel = 0;
    nrf_saadc_value_t buf_adc;

    nrf_saadc_channel_config_t aread = {

        .resistor_p = NRF_SAADC_RESISTOR_DISABLED,
        .resistor_n = NRF_SAADC_RESISTOR_DISABLED,
        .gain       = NRF_SAADC_GAIN1_6,
        .reference   = NRF_SAADC_REFERENCE_INTERNAL,
        .acq_time   = NRF_SAADC_ACQTIME_40US,
        .mode       = NRF_SAADC_MODE_SINGLE_ENDED,
        .burst      = NRF_SAADC_BURST_DISABLED,       ///< Burst mode configuration.
        .pin_p      = NRF_SAADC_INPUT_AIN2,
        .pin_n      = NRF_SAADC_INPUT_DISABLED
    };

    nrf_saadc_channel_init( channel, &aread );
    nrf_saadc_resolution_set(SAADC_RESOLUTION_VAL_10bit);

    memset( &buf_adc, 0, sizeof(buf_adc) );
    nrf_saadc_buffer_init( &buf_adc, 1 );
    nrf_saadc_oversample_set( NRF_SAADC_OVERSAMPLE_DISABLED );
    nrf_saadc_continuous_mode_disable();

    nrf_saadc_enable();
    while( !nrf_saadc_enable_check() ){}

    nrf_saadc_task_trigger( NRF_SAADC_TASK_START );
    while( !nrf_saadc_event_check( NRF_SAADC_EVENT_STARTED ) ) {}
    nrf_saadc_event_clear( NRF_SAADC_EVENT_STARTED );

     nrf_saadc_task_trigger( NRF_SAADC_TASK_SAMPLE );
    while( !nrf_saadc_event_check( NRF_SAADC_EVENT_RESULTDONE ) ) {}
    nrf_saadc_event_clear( NRF_SAADC_EVENT_RESULTDONE );

    nrf_saadc_task_trigger( NRF_SAADC_TASK_STOP );
    while( !nrf_saadc_event_check( NRF_SAADC_EVENT_STOPPED ) ) {}
    nrf_saadc_event_clear( NRF_SAADC_EVENT_STOPPED );

    return buf_adc;

}

I don't understand why, after lpcomp operation, disabling lpcomp, doing ADC, and then enabling lpcomp again causes normal operation.

* Additionally, there are five products with identical circuitry and SW configurations, but with different PCB patterns.

However, this issue only occurs in one of the five products. The only difference is the PCB pattern.

The PCBs with the pattern differences are located at 1M and 2M, and the pattern distance between the 1nF resistor and the ADC port is approximately 15cm. (The lines indicated by the arrows in the image below.)

However, the four PCBs that are functioning normally are almost directly adjacent.

Could this be the cause?

   

Parents
  • Hi there,

    I see that you already have 2 other tickets related to this one issue, let's try to avoid creating a new thread as it makes it even more difficult for us to find all relevant information for your case. If you feel like we've missed your reply or used too long time to get back to you, then you are absolutely encouraged to remind us by updating the previous tickets. 

    I read the two cases, and immediately I have some comments:

    1. My colleague   had a really good suggestion, in that you should try to switch the IC between a good and bad board. If the issue follows the chip then we are much more sure that this is a HW issue related to our chip and not something external.
    2. The LED logic complicates the debugging a bit, instead of using a LED to tell if the voltage has passed the threshold, can you use the log module? Do you already have the log module available? 
    3. Try to circumvent the VBAT + LDO and voltage divider circuitry with a bench top supply. Feed the IC a known reference voltage from the supply and the LPCOMP input and see if you can reproduce the same behavior.

    Please update the previous tickets. 

    best regards

    Jared 

  • Hi

    Thank you for your quick reply.

    .

    My colleague   had a really good suggestion, in that you should try to switch the IC between a good and bad board. If the issue follows the chip then we are much more sure that this is a HW issue related to our chip and not something external.

    I haven't tried it yet.

    I'll try it and let you know.

    .

    .

    .

    The LED logic complicates the debugging a bit, instead of using a LED to tell if the voltage has passed the threshold, can you use the log module? Do you already have the log module available? 

    I tried this implementation.

    I tested it by turning on only the LED and seeing if it would operate properly at low voltages, and I also used debugging to verify it.

    .

    .

    .

    Try to circumvent the VBAT + LDO and voltage divider circuitry with a bench top supply. Feed the IC a known reference voltage from the supply and the LPCOMP input and see if you can reproduce the same behavior.

    I'm experimenting with a separate, precise external DC power source (instead of a battery).

    I switched to the ADC mentioned above, and measured the voltage across the 1M and 2M resistors when the voltage was normal and when it wasn't. The results were nearly identical.

    By any chance, are you saying that I should try to adjust the voltage by directly connecting it to the lpcom terminal?

    .

    .

    .

    Please update the previous tickets. 

    - Question 2)  The reference voltage setting of lpcom does not match the calculation  

    Shall we continue the question here?

  • Hi,

    pkr2258 said:

    I tried this implementation.

    I tested it by turning on only the LED and seeing if it would operate properly at low voltages, and I also used debugging to verify it.

    What I'm suggesting is that you decouple the LED from your debugging as it introduces other dependencies. Instead use the log module or just measure directly on a GPIO.

    pkr2258 said:

    I'm experimenting with a separate, precise external DC power source (instead of a battery).

    I switched to the ADC mentioned above, and measured the voltage across the 1M and 2M resistors when the voltage was normal and when it wasn't. The results were nearly identical.

    By any chance, are you saying that I should try to adjust the voltage by directly connecting it to the lpcom terminal?

    Yes, I'm suggesting that you circumvent the external LDO as well, connect VDD to port 1 of supply and then connect AIN to another supply and see if your code logic behaves as expected when VDD is decreased.

    pkr2258 said:
    Shall we continue the question here?

    You can continue here

    best regards

    Jared 

Reply Children
No Data
Related