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.

ADS 1148 problem

Other Parts Discussed in Thread: ADS1148

I have a problem to communicate with the ADS1148:

Reading the registers works but writing the registers does not work:

I do the following:

Start and CS high, Reset low, waiting 1ms

Reset high, waiting 20ms

SPIClk is 0.5MHz, clk idle is low, data change is at rising clk, data sample at falling clk.

Read MUX0: CS low, send 0x20, 0x00, 0xff => answer of the last byte 0x01 which is the default value, CS high

Read IDAC0: CS low, send 0x2a, 0x00, 0xff => answer of the last byte 0x90 which should be the revision ID, CS high

Read IDAC1: CS low, send 0x2b, 0x00, 0xff => answer of the last byte 0xff which is the default value, CS high

What I observe: The DOUT signal goes to high at the last clock of the second byte, is this OK?

So reading seems to work. What I observe: The DOUT signal goes to high at the last clock of the second byte, is this OK?

Now I want to write:

Write IDAC0: CS low, send 0x4a, 0x00, 0x0e (DRDY Mode 1 and 1mA IDAC) , ignore answer, CS high

Write IDAC1: CS low, send 0x4b, 0x00, 0x34 (I1 at AI3, I2 at AI4) , ignore answer, CS high

Reading back these registers like above will send me the old original values.

I also observe the DOUT signal goes to high at the last clock of the second byte. is this OK?

Should I wait for something? Unfortunately I didnt wire the DRDY signal to the micro, only the DOUT/DRDY.

Please help, thanks

Stephan

  • Stephan,


    Are there any other commands sent at startup? I was curious if you had issued an SDATAC command so that the DOUT register isn't updated with data every time the converter completes a conversion.

    I've looked through your procedure and it looks correct. I'm not sure I understand the comment about DOUT going high at the last clock of the second byte (this would be the number of registers being read). In the end, if you're able to read out the device, it should be ok.

    The best thing I can advise is to get an oscilloscope or logic analyzer to look at the bits being toggled to make sure the SPI communications are correct during the write. Make sure that RESET isn't toggled. A reset will revert the register settings back to the default values.


    Joseph Wu
  • Hi Joseph,

    I think I have found the problem!
    I always read and write one register only.
    So I also send and request only one data byte, so overall 3 Bytes for the whole protocol.
    This seems to work when reading, but not when writing.
    So I changed that to 4 bytes, second byte still 0 for requesting or writing one byte only, and I ignore the last byte when reading and send 0 when writing.
    Now I can write the registers!!!
    Does this make sense?
    I didn't find any comment in the documentation to always send 16Bits also if only 8 Bits needed.
    Am I on the right way?

    Best regards

    Stephan
  • Stephan,

    Just to be sure I understand, you're now sending a second byte as a dummy byte to write to the registers, because the part has been ignoring the byte?

    The part shouldn't work this way. However, based on previous comments, I think I know what might be wrong. You'll have to check this with an oscilloscope, but I think you have a timing violation. If you look at the timing diagram on page 12 of the ADS1148 datasheet, you might be violating the tsccs specification. This is the delay time required between the fall of the last SCLK to the rise of /CS line. This time is 7 oscillator clock cycles, which might be more than one would expect.

    If you have the chance, check to see if this is the issue and try to extend the /CS low time after the last SCLK and see if this fixes the problem.

    Joseph Wu

  • Hi Joseph,


    you are totally right! The CS came to early.

    Now, I removed the dummy byte sending and added a short delay after the last SCLK and now, everything works perfect!

    Many thanks!

    Stephan

  • Stephan,


    I'm glad the suggestion worked out for you. If you have any more questions, please feel free to post back on the forum.


    Joseph Wu