• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 4 answers
  • Subscribers 63 subscribers
  • Views 412 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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:

BQ76PL455A-Q1: TI Checksum test problem

BQ76PL455A-Q1: OVERSMPL 32 x CMD_OVS_CYCLE = 1 won't respond?

Jeffrey Wright
Expert 2875 points
Part Number: BQ76PL455A-Q1
Other Parts Discussed in Thread: BQ76PL455A, ADC141S626

I hope I'm keeping you busy with all my questions ;-D,...but here goes yet another -  When OVERSMPL = 7D (32 samples each channel), my results are good. But when I reprogram to FD (32 samples, 1 per pass), the AFE stops responding. When querying its registers, they all report correct (OVERSMPL = 0xFD), but it won't reply to my read ADC command. Resetting it back to 7D gets it running again, or 0x7B as well....just on 0xFD ???

Thanks again in advance!

  • 0
    TI__Genius 17370 points
    Hi Jeffrey,

    Yes - all good questions though. We generally always point users to follow the recommended datasheet specs for sampling to get the best accuracy as those conditions have been characterized to report the best possible accuracy. This includes using 0x7B for this and ensuring to use a 390pF OUT capacitor. What value are you using for this and the ADC period values?

    Best Regards,

    Taylor
  • 0 in reply to Taylor Vogt
    Expert 2875 points

    I'm using your EM1402 eval board, and so I'm assuming it's using a 390pF.  The default oversample setting (0x7B) produces OK results, but using 32 (0x7D)  produces better results. But again, if I set OVERSMPL to 0xFD, it won't respond.

  • 0 in reply to Jeffrey Wright
    TI__Genius 17370 points
    Hi Jeffrey,

    I tested this on pl455a EVM and it works normally using 0xFD. Can you explain what happens when it doesnt respond? Are you using example code or the GUI to talk to the device?

    Thanks,

    Taylor
  • 0 in reply to Taylor Vogt
    Expert 2875 points

    Hi Taylor;

    I'm testing the driver I wrote - the other combinations work - i.e. 7D, BC, etc. But when setting OVERSMPL to FD, it doesn't respond to a conversion request. I'll have my client's tech repeat this test using the TI GUI.

  • 0 in reply to Jeffrey Wright
    Expert 2875 points
    Hi Taylor;
    Nevermind (again). I found the trouble this AM...My driver includes a timeout while waiting for replies from the AFE. As it turns out, when setting the OVS bit in the period register (FD), the overall AFE read time (command + conversion time) on 13 cells + 2 Aux channels x 32 samples, increases from under 9ms (7D) to just under 28ms ...and my timeout was set to ~10ms. After increasing my timeout to ~32ms, I was able to read the AFE.
    HOWEVER, the issue of noise is still there. We still see ~+/- 400 uV of jitter over time, and ~+/-500uV on the top channel (13). And that's on both setups: my driver and TI's GUI. We really need to confirm these results with your testing to determine if this is a layout issue on the EM1402, or its the 455 itself.
    Thanks!
  • 0 in reply to Jeffrey Wright
    TI__Genius 17370 points

    Hi Jeffrey,

    I attached a log file of data collected from the GUI and +-1mV is relatively normal so if you are seeing +-500uV now then I do not think you have an issue with the bq76pl455a. Since you seem to have better data with 32x oversampling - then I would recommend moving forward with those settings to get better performance. 

    Cell13.xlsx

    Best Regards,

    Taylor

  • 0 in reply to Taylor Vogt
    Expert 2875 points
    Thanks Taylor;
    I've passed this info along to my client, but they're still concerned with what could account for this jitter. They're checking to confirm, but they say there current jitter is much less (using the legacy EMB1432 + EMB1426).

    I initially speculated that the EM1402's layout was wanting, but after seeing that captured noise during conversions, I'm dubious, given that the input is very stable (both a 60V bench supply and a 48V battery).

    Referencing the attached scope capture, I note that the ~4us glitches seem curiously close to a 250kSPS conversion....And since I'm guessing that the 455's 14-bit ADC is no other than the EMB1426 (which is the 250kSPS ADC141S626, or a modified version), I'm wondering whether the SAR logic/clock may be the source of the noise, and if so, perhaps additional decoupling could help (?)

    Since you're seeing about the same level of jitter, can you please have engineering confirm the source of this noise? i.e. is this intrinsic noise that cannot be filtered, or is this a layout issue.

    Thanks in advance!
  • 0 in reply to Jeffrey Wright
    TI__Genius 17370 points
    Hi Jeffrey,

    With +-1mV noise this is likely intrinsic noise simply due to the LSB swinging in ~100uV range and this is expected and unavoidable. This type of accuracy is typically received positively in the industry and there is not much we can do for this unless you would like to take it upon yourself to experiment with decoupling. We apologize if this is causing any inconvenience to your system.

    Best Regards,

    Taylor
  • 0 in reply to Taylor Vogt
    Expert 2875 points

    Hi Taylor;

    I appreciate all your help, and you've solved most of my issues.

    However, this issue is particularly troublesome, since it appears to be systematic, and so may not be solvable.  The trouble is, if you refer to my first post on this issue (...This means the "noise" is ~+/- 3 LSB, on all cells but 13, which is ~+/- 5 LSB...), the jitter is much larger than 1 LSB, which would be acceptable.   And it's not inaccuracy that's at issue, since it can be calibrated out...if the results are stable, which unfortunately they're not.

    Since you initially indicated that you were unfamiliar with this issue, I would greatly appreciate it if you could get definative feedback from an engineer who is responsible for the support of this product. If your last reply was based upon engineering's definative feedback, I'll discuss with my client about potential ways forward...

    Thank you for your help!

     

     

  • 0 in reply to Jeffrey Wright
    TI__Genius 10785 points
    HI Jeff,

    Please refer to other thread that related to this issue.

    Roger