• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 46 subscribers
  • Views 153 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

TLA2528: Conversion Time

TLA2528: Clock stretch time with averaging

Andrew Greensted
Prodigy 250 points
Part Number: TLA2528

Tool/software:

I'm looking for clarification on the expected clock stretching time when averaging is enabled.

My current device configuration is:

OSR = 4 (16 samples averaged, See Table 13, Page 25)

OSCL_SEL = 0 (High Speed oscillator, See Table 4, Page 16)

CLK_DIV = 6 (125 kSps, 8 us cycle time, See Table 4, Page 16)

Figure 24 suggests that the clock stretch time is tconv * OSR_CFG[2:0]. There are a few things wrong with this, 1) how does this take into account the cycle time, 2) the value stored in OSR_CFG[2:0] isn't actually the number of samples averaged.

I'm wondering if the clock stretch time should actually be tcycle * 2^OSR_CFG[2:0]

For my configuration this would give 8 us * 2^4 = 128 us. Here is a capture of SDA and SCL confirming this time. 

As others have identified, the TLA2528 datasheet contains errors. Is this another one? When can we expect a corrected datasheet?

  • +1
    TI__Genius 15510 points

    Hi Andrew,

    In regard to datasheet updates, the best way to make us aware is by clicking the "Submit Document Feedback" button at the bottom of each page on the datasheet. This will direct you to an intake form where you can leave information on datasheet errors. 

     

    I think I see what you are saying and how it's not totally clear. OSR_CFG[2:0] doesn't directly contain the samples averaged together. Like in your case, your register setting is 100b (4 in decimal), which corresponds to 16 conversions. Maybe it could be clarified that it is not the actual register setting, but the corresponding oversampling ratio selected. I've taken note of this as a potential update.

    t_conv should likely be updated to t_cycle, according to the OSC_SEL and CLK_DIV[3:0] register field settings, since t_conv is only defined as t_stretch, which is only defined for one-shot conversion mode.

    Your interpretation is definitely correct, and is what the datasheet is intended to state, so there is room to improve how that is communicated. At the moment there is no timeline to when the datasheet will receive a revision, but this is definitely something that will prompt any changes and be included in the next one.

    Regards,
    Joel

  • +1 in reply to Joel Meraz
    Prodigy 250 points

    Hi Joel,
    Thank you for the response and the clarification of my interpretation of the datasheet.
    I'll submit and 'Document Feedback' using the link you describe, that's a really nice thing to have on the datasheets.

    With regards when the datasheet is updated, I'd hope datasheet clarification would be a high priority for TI. In the long run, surely it will lead to less support queries and happier customers!

    I'm sure for many companies, a device datasheet is a vital point of reference when authoring internal design documentation. In this example, an I2C timeout period has been set based on the clock stretch time of the TLA2528. Without that information being correctly documented in the part's datasheet, there's no direct justification and evidence for our design decision. Given that the datasheet includes actual mistakes (STATS_EN bit), hopefully a new datasheet revision will be published soon!

    Thanks again.