• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 2 answers
  • Subscribers 45 subscribers
  • Views 523 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.

ADS7882 timing and microprocessors...

k1mgy
Expert 1680 points
Other Parts Discussed in Thread: ADS7882, MSP430F5659

ADS7882
either MSP430F5659 or Atmel XMEGA256A3

Issue: The RESET sequence for the ADS7882 has strict timing to read the data buss.  CPU at 24MHz has cycle time that, combined with code latency, simply cannot make the PWD_RST bytes appear at the device I/O.  At least, this is my present hypothesis.

Or, maybe the issue is me :)

Is this a correct understanding of the use of PWD_RST?

1. PULL  LOW:   CS, CONVST, RD 
2. PULL HIGH: A_PWD  (I leave it there)
3. PULL HIGH: PWD_RST
4. Wait a few microseconds
5. PULL LOW: PWD_RST and keep low 
6. Immediately read data bus DB0-DB11 where 0xFE0 should be present
7. WAIT for no more than 6140 nS
8. PULL LOW: PWD_RST and keep HIGH

With a 24MHz clock I am assuming a __no_operation() (equivalent to 1 CPU cycle) is approximately 42ns.  So I use some of these to establish the minimum timing,

Occasionally I get some data on the bus, but mostly 0x000.

I'm using this PWD_RST data read back to confirm I have a good chip and buss.  I trust both at this point, and think the problem is in the timing.  

Note: I have enabled and disabled pullups on the bus.  No difference.  Does this device require pullups?

Ideas anyone?

  • 0
    Expert 1680 points
    TI, can you comment here please?
  • 0
    TI__Mastermind 45895 points

    Hello k1mgy,

    Sorry for late response. I have few questions which can help me to understand your timing well:

    1. In step 8, are you pulling low or high for PWD_RST pin? I'm confused because you mentioned "PULL LOW: PWD_RST and keep HIGH".

    2.  After step 8, did you send any signals on /CONVST and /CS for data conversions? if yes, did you see any BUSY pulses?

    To check the device, the simpler, the better for the first step without any nap or power down mode, just use /CONVST, /CS, /RD and data bus, keep /A_PWD and /PWD high, then check BUSY signal.

    Thanks.

    Best regards

    Dale Li

  • 0 in reply to Dale Li
    Expert 1680 points

    Dale, thank you.  

    I've been pounding away on this and finally reached a solution, but I do have another question.  

    What happened: To get good reads I followed the exact sequence laid out in the DATA READ timing diagram on page 9 of the data sheet.  This, after a lot of frustration working with the sequencing in the Sampling and Conversion Start section on Page 8.

    I was confused by all three examples in Figure 3, as these described acquisition modes, all three of which have CONVST go HIGH.  The confusion was amplified when I then looked at DATA READ.. not realizing that it picks up on the left side with CONVERSION (after the acquisition is complete).

    We need to trigger a series of around 10 very fast ~~2.5MS/S complete acquisition+conversion+read cycles.  Can you suggest to me the needed sequencing to accomplish this?  

    Presently I am doing test sampling, so it's very slow.  Pseudo-code below:

    // perform a RESET sequence
    // takes 1590ns

    RESET HIGH
    _delay_ms(1);
    RESET LOW
    //READ 12 bits (takes 430ns)
    RESET HIGH
    READ DATA and make sure it's 0xFE0

    // Read Loop

    _delay_ms(1);

    CONVST HIGH // 172ns
    CS HIGH // 172ns
    READ HIGH // 172ns
    RESET HIGH // 172ns

    _delay_ms(1000);
    TEST BUSY FOR LOW (loop here until low)
    CS LOW  // 172ns
    _delay_ns(43);  // wait 1 clock cycle
    CONVST LOW  // 172ns
    CS HIGH  // 172ns
    TEST BUSY FOR LOW (loop here until low)
    CS LOW // 172ns
    CONVST HIGH // 172ns
    RD LOW // 172ns
    READ DATA // approx 1200ns
    _delay_ms(1000);

  • 0 in reply to k1mgy
    TI__Mastermind 45895 points
    Hi k1mgy,
    Your program code uses a lot of delays and the query method to check BUSY signal, which makes the execution and response very slow. The data reading can be execute during acquisition phase and both of them can be implemented at the same time. The maximum Tconv is 280ns and the minimum Tacq is 53ns, so the total cycle can be 280+53=333ns and this can achieve approximate maximum 3Msps throughput(td1_typ 4ns is not considered here) which is supported by ADS7882. The timing in DATA READ section( Figure 5 in Page 9 of ADS7882 datasheet) has included the conversion and data reading,
    1. please follow up this timing exactly without BYTE(keep low on BYTE pin)
    2. use a timer in CPU for the /CONVST to implement exact sampling control
    3. use interrupt method the check BUSY's falling edge
    4. read the data in interrupt subroutine with /CS and /RD signals
    You will get faster sampling rate and the conversion data. Please let me know if you have more questions.
    By the way, the timing figures in page 8 use different timings for different conversion start control.

    Best regards
    Dale Li