AD7124-8 Internal temperature sensor conversion cause AINM_UV_ERR

Hello :) 

We're implementing an AD7124-8 as the main ADC in test equipment and I am in the process of writing up the firmware for controlling the module where the ADC is placed. I would like to measure the die temperature of the ADC to perform auto-calibration when large temperature changes happen. 

I had gotten what seemed to be believable temperature conversions from the built in temperature sensor, but then I enabled error handling for the conversions, thereby including the conversions made for the internal temperature sensor, and now I get AINM_UV_ERR for every conversion with the internal temperature sensor. 

I have following configuration for the channel (Channel 7) that converts the internal temperature sensor: 

- AINP = 16/Temperature sensor

- AINM = 17/AVss

- Setup = 4

The configuration and filters are set as follows (for setup 4)

- Internal reference 

- Bipolar 

- 1 x Gain 

- FS = 32 

The conversion is done by enabling the channel and doing a single conversion in full power mode. Reading the error register following that, reveals that AINM_UV_ERR gets set. 

As I said, the resulting temperature (if you ignore the error and read the conversion result) seems reasonable, so is this just expected behaviour? Can I believe the results I am getting, and just ignore the undervoltage error? 

br. 

Kenneth

  • Hi,

    Is it possible for you to probe the AINM (pin17) to GND and share the voltage value here? so we can evaluate why the AINM_UV_ERR pops up.

    Regards,

    Andrei 

  • Hello 

    Maybe I should have explained it a bit clearer, but its not using Pin 17. It is muxed via the internal mux to AVSS aka. 17 (Decimal) in the AINM field of the channel register. This means that the converter is connected to the internal temperature sensor, with AINP to the temperature sensor (16 decimal in the AINP field), and AINM is connected to AVSS (17 decimal in the AINM field). I hope this clears things up how the internal mux is configured. 

    /Kenneth

  • Hi,

    Apologies for confusion. We have tested and guaranteed that every part will trip at 40mV outside the rails as shown in the figure in the datasheet. However, you will see that other parts may also trip at different voltages near the rails and this varies from part to part, that is why we do not have a specs for this listed on the datasheet. The diagnostics uses a comparator and this not very precise and could have some offset errors. Some parts may trip at the rails and some are above or below the rails. So the flags can trip anywhere from the rails (AVSS/AVDD) to 40mV outside the rails. And like I said, the overvoltage/undervoltage checks are done using comparators so the checks occur on the analog input being measured and not upon conversion. The check is also continuously performed. So if you are using AVDD/AVSS as your input and the UV/OV error is enabled, the flag could be possibly set. 

    And this is the case on using internal temperature sensor as it works in conjunction with AVSS. 

    May I know how important the UV/OV errors in your system?

    Thanks,

    Jellenie

  • Okay, that would explain it! Loose detection of UV/OV, which I did notice in the datasheet to be a seperate circuit in the IC, just like you said, a seperate set of comparators. Tripping these errors doesnt necessarily mean that the converter itself is outside of the valid region, it is just the error detection that is too inaccurate to detect it. So just like I suspected in my first post, the converter result is valid, I will just have to ignore the UV/OV errors when performing temperature readings. 

    In the rest of my system I am not measuring near the rails, so in any other case than the temperature conversion I should still be able to use the UV/OV detection (While it might limit my range a bit if they have inaccurate tolerances) But the most important thing is that I know I get valid conversions, which these error checks should guarantee. 

    I consider my question answered! Thank you for your help 

    /Kenneth