TLA2024: TLA2024 – Inconsistent Config Register Defaults & OS Bit Not Setting During Single-Shot Conversion

Part Number: TLA2024


Tool/software:

Hi,

We’re encountering unexpected behavior with the TLA2024 ADC during initialization and single-shot operation.

The Issues:

  1. Config Register Default (0x02):

    • On power-up or reset, the configuration register (0x01) reads 0x0083 or 0x0183, inconsistently.

    • This does not match the datasheet default value of 0x8583.

  2. Single-Shot Conversion Behavior:

    • When initiating a single-shot conversion by writing 0xC383 to the configuration register, the OS bit (bit 15) never reads back as 1.

    • It remains 0 even immediately after the write, contrary to what’s expected per the datasheet.

    • However, the conversion register (0x00) does update with a new value, suggesting the conversion is actually happening.

Our Setup:

  • Host MCU: nRF54L15

  • Supply: 3.3V

  • Address: Default (ADDR pin to GND) 0x48

Cheers,

Callum

  • Hi Callum, 

    Welcome to the Texas Instruments E2E forum!

    I just have a few clarifying questions to help my understanding of your issue:

    1. For the Config Register Default issue is this reading right after start-up? Is there any delay? Do you read it once or multiple times?

    2. Can you share some scope captures of the behaviors you are seeing?

    3. How much time after the write of the start conversion do you read out the OS bit?

    4. Can you share a little more information about the system as a whole? 

    5. Are you reading out the expected value? i.e. input 1V output 1V in ADC codes.

    Regards, 

    Andrew

  • Hi Andrew, 

    Thanks for the quick response.

    1. We read them right after power up, maybe 10 ms after applying power. We've done both, read once and multiple times. It's always the same (either 0x0083 or 0x0183). Same behavior happens when we sent i2c reset command.
    2. We don't have easy access to i2c bus to scope on our custom boards since they are quite dense. The micro is not reporting any i2c errors so it should be ok. If we narrow it down to this, we can figure out a way to get some data.
    3. We start the conversion and wait 1/DR + 100us, the we read the OS bit and continue doing so every few miliseconds until about 200ms elapsed. It never turns 1. We've also tried looping forever, also never turns 1.
    4. I've attached some relevant schematic snippets. Some of the data is sensitive, so if you would like a full schematic I can privately share it. Our MCU is a Nordic nRF54L15.
    5. We believe the conversion value is accurate.

  • Hi Callum, 

    Thank you for the information. 

    Do you have multiple TLA2024 devices that this behaviors is seen on, or has it been isolated to this specific device? 

    When you write configuration data in ex. 0xC383  are you able to read the correct configuration out?

    Here's a few experiments that could help narrow down the issue:

    Experiment 1: Startup Data Read 

    On the startup take a single conversion write to the OS bit to perform a single conversion to confirm the settings the device is in upon start up. By reading the output codes this should be easy to see which FSR register value is being used by the device. Potentially the device is in the default register settings but its not reflected in the configuration register. 

    Experiment 2: Single Shot Current Scope 

    Monitor the supply current when performing a single shot conversion. The device should start at ~0.5uA, rise to ~150uA while converting and fall back to 0.5uA when the conversion has completed. This can help determine if the device is operating correctly in the single shot mode / power down mode by cycling back into the power down once the conversion is complete. 

    Experiment 3: Writing 0xFF83 to the device

    A small adjustment to the voltage divider at AIN3 by changing R39 to have the input fall between the FSR +/- 0.256V. This can isolate the change from the default to the two bits that are not setting to the exacted default from the power-up reset. 

    Regards, 

    Andrew

  • Thanks Andrew for your assistance. It turns it it was a conflicting I2C address so we we're only receiving information back on the first bytes of a message. Removing the other I2C chip we can communicate fine with the TLA ADC.

    Sorry we missed this conflict.