• Resolved

ADS1299 Startup

I have a question about the startup timing for the ADS1299.  We have a custom board design with multiple ADS1299 converters.  Most of the time it is working fine, but occasionally a few channels don't power up correctly.  Its roughly one time in about 50 powerup cycles, and the results are a little random.  I've seen alternate channels on one ADC affected, all the channels on one ADC affected, and other combinations.  Sometimes the output is fixed at zero, but mostly they are saturated high or low.  The input is always driven, sometimes with a few millivolt AC signal, mostly with zero (a few millivolt DC offset).  It looks to me like the PGA configuration is not correct, but I haven't investigated it too deeply and I could be wrong on that.  Powering the board down and restarting it has so far always cleared the problem.


The PowerUp Sequencing section of the data sheet (page 57) says there should be 2**16 clock cycles from power supplies up to Reset.  At the 2.048MHz clock we are using that should be about 30msec.  We are using the SPI reset command issued by a CPU on the same power supply as DVDD for the ADC, but need to wait at least 100mS before issuing the reset command or it doesn't startup correctly most of the time.  The frequency of startup errors does seem to be tied to that delay time, but its not a linear relationship.


The flow chart on the following page says to wait 1 sec before resetting.  That seems like a pretty long time.  We can tolerate the delay if necessary, but we tried it and even at that delay I had one or two times that it didn't power up correctly.

What is the required delay from powerup to reset and do you have any other ideas on how we can prevent this from happening

Tom

  • Hey Tom,

    The startup sequence in the datasheet is known to work from our testing with the diagrams and charts on page 57 indicating the minimum timings allowed. Could you send over your schematic and your exact startup sequence for me to review?

    Regards,
    Brian Pisani
  • In reply to Brian Pisani:

    Brian,

    The schematic is attached.  I only included two of the five A/D converters and the micro driving them.  The other three are essentially the same.  This should give you everything you need to know, but let me know if it doesn't.

    The startup sequence is as follows:

    After processor startup, a timer is started.  Other things get initialized while it is waiting to set up the ADC.  After the timeout period, the ADC configuration registers are written as follows:

    1. Write 00h into all channel set registers (starting with 0Ch, ending with 05h), reading each one back as we go. This is done with single byte commands.
    2. Write configuration register 01h with 95h (sample rate of 512, daisy-chain enabled). Read back for verification.
    3. Write configuration register 02h with D1h (internal calibration at default amplitude and double frequency). Read back for verification.
    4. Write configuration register 03h with E8h (enable the reference buffer, and generate the BIASREF signal internally). Read back for verification.

    We do not currently reset the ADC as the spec requires.  We did try issuing a RESET command over the SPI interface at the start of the initialization and waiting longer than 18 clock cycles required.  It did not have any effect that we could detect.

    The initialization timeout is currently set to 250msec and startup errors are rare.  At 125msec they were more common, but still fairly rare.  At 100ms the startup errors were quite frequent.

    I am out of the office tomorrow, but on Friday I will add the RESET command back in and shorten the delay time back to 100msec and see if I can get more detail on what is happening and how often.  Let me know if you have any other suggestions to try.

    Tom

  • In reply to Tom Moyer:

    Hey Tom,

    For whatever reason I was unable to download your schematic. Try attaching it again, but this time click "Use rich formatting" and use the paperclip symbol to browse your file system for the file. Out of curiosity, what happens if instead of multiplexing all the channels to normal electrode mode, you configure them to convert the test signal by Setting CHnSET[2:0] to b'101?

    Regards,
    Brian Pisani
  • In reply to Brian Pisani:

    Brian,


    As I was pulling together the information for your last request, I realized a number of things I thought were happening at startup were not actually happening.  I've been juggling this with some other priorities, so it's taken longer than I had hoped, but I think we are now following all the timing guidelines in the data sheet and we're still having trouble.

    Our startup sequence is as follows:

    Wait 20msec for power to stabilize

    Enable main clock (2.097MHz oscillator)

    Wait 38msec

    Issue SPI reset command

    wait 1 msec

    Issue StopContinuousMode command

    Set Channel Registers to 0x00

    Set Config Register 1 to 0x95

    Set Config Register 2 to 0xD1

    Set Config Register 3 to 0xE8

    readback channel and config registers to verify they are set correctly

    The initialization issues seem to be specific to certain chips.  Some of the 5 ADS1299 always configure OK, some are OK sometimes and not OK other times.  The ones that are intermittant vary between different boards, so I don't think it's due to a PCB issue.  The symptoms of a misconfigured device vary.  The outputs are often, but not always saturated, and if they are not the noise level is very high (several millivolts typically).  The two consistent things we have found so far is that a misconfigured device will not read back the configuration registers;  All reads return 00's.  I assume this is because any SPI read is read data registers, regardless of what commands may have been sent, but I don't have any way to confirm that.  The second consistent thing is that setting the channel mux to the test pattern setting saturates the output, usually positive, but occasionally negative.

    I will continue to dig into this issue, but any help you can offer would be appreciated.  Someone just reminded me that we do have and ADS1299 eval board here, so we will look for differences from that as well.

    I tried your suggestions for uploading the file, but without success so far.  I am working on a Linux machine, so I will try loading it from Windows and try a few different browsers as well to see if I can get one of them to work.


    Tom

  • In reply to Tom Moyer:

    Hey Tom,

    Looking at your schematic and reading through the startup routine description, I don't know what could be causing this issue. I have never seen it before and I cannot think of a configuration change that would cause this. Especially confusing is the test signal. On failing devices, can you probe the following voltages? I will provide the ideal values.

    VCAP1: 1.2 V
    VCAP2: (AVDD+AVSS)/2
    VCAP3: AVDD + 1.9 V
    VCAP4: (VREFP+VREFN)/2

    Regards,
    Brian Pisani
  • In reply to Brian Pisani:

    Brian,

    Good suggestion. It looks like the reference is not being powered up either. VCAP4 is measuring 12mV on one misconfigured converter and 56mv on another. I will look into that a little deeper, but wanted to pass the initial information on.

    Also, the only reliable way of clearing the problem is to power the unit down and restart it. We tried driving the powerdown pin on the ADS1299 when we detect the misconfiguration, but that only clears the error on some chips but not on others. We also tried resetting with both the reset pin and the reset SPI command, but that had no effect.

    The misconfiguration also seems to only occur when the board has been powered off for at least several seconds. I have not seen the chips misconfigured when the unit is powered down and back up in less than a second.

    Hope all these symptoms add up to some clues that can lead us to the source of the problem.

    Tom
  • In reply to Tom Moyer:

    When the device is misconfigured, the Vref+ pin also measures low (0.120V on the part I checked, Vref- is tied to ground).
  • In reply to Tom Moyer:

    Hey Tom,

    I checked with one of my colleagues and neither of us have seen this specific set of symptoms before. I initially thought it could be an issue with startup timing, but you mentioned that you have extended the time in between steps in the sequence to no effect. Have you assembled a few boards? If you have do the same sockets on each board exhibit issues or is it totally random?

    Regards,
    Brian Pisani
  • In reply to Brian Pisani:

    Brian,

    We have assembled several boards and which chip is affected seems to be random. We have some boards that rarely exhibit any problem and others that frequently have problems with multiple chips. The behaviour of any specific chip on a specific board is pretty consistent, but across boards there is no pattern I have been able to detect.

    The problem initially appeared to be significantly improved by delaying the startup, but there was a number of steps missing at that point. On Monday I will see if there is any correlation between the startup delay times and the misconfiguration problems.

    Tom