• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 46 subscribers
  • Views 602 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.

ADS1258: SPIRST resets SPI Interface when not expected

Konstantinos Vasiliou
Prodigy 20 points
Part Number: ADS1258
Other Parts Discussed in Thread: ADS1158

Hello,

I am using the ADS1258. the CLK frequency is 12.5 MHz, SCLK frequency is 1.5625 MHz.

The ADC is running in Auto-Scan mode. Te register condiguration is  the following:

CONFIG0 0x56
CONFIG1 0x40
MUXSCH  0x00
MUXDIF    0x3F
MUXSG0   0x00
MUXSG1   0xF0
SYSRED   0x00
GPIOC       0x00
GPIOD       0x00

The sequence is:

1. Write ADC configuration

2. Send pulse convert command 0x80

3. Wait for conversion

4. Read channel data 0x30

I see that the SPI interface sometimes goes into reset even when SCLK is active, missing the last byte of the channel data value.

The SPI goes into reset ~20,84 µs after the communication starts, that is 256 fclk cycles.

From the datasheet, I understand that the SPI interface should not go into reset while SCLK is active.

Have you observed this behaviour before?

  • 0
    TI__Guru** 113765 points

    Hi Konstantinos,

    Welcome to the E2E forum!  I don't believe that the SPI is being reset.  The outcome shown is what I would expect if the device is actually an ADS1158 (16-bit version of the ADS1258).  Have you verified that the device ID bit is as expected? Read back register address 0x09 and check bit 4.  If this bit is set to 1, then the output format would be 16-bit.

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    Prodigy 20 points

    Hi Bob,

    I can confirm that the device is ADS1258.

    Readback from register address 0x09 gives the value 0x8B.

    On the device I can read the following:

    AD1258MEP   

    39T  

    AJTC

  • 0 in reply to Konstantinos Vasiliou
    TI__Guru** 113765 points

    Hi Konstantinos,

    So I then assume that sometimes the data comes out as you would expect.  Can you send me logic analyzer shots of when it is working for comparison?  Have you seen any pattern as to when it is working and when it isn't?  For example, it always happens on a specific input channel.

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    Prodigy 20 points

    Hi Bob,

    Here are the screenshots of when it is working and when it is not working:

    Working:

    Not working:

    All the channels are either working or not working at any time. This behaviour comes periodically.

    I think it has to do with clock-domain crossing inside the chip regarding the SCLK detection.

  • 0 in reply to Konstantinos Vasiliou
    TI__Guru** 113765 points

    Hi Konstantinos,

    The SPI timeout operates such that if SCLK is idle for a period of time, the SPI internals will reset.  The reset would be similar to taking CS high.  You could test your timeout theory by using the default setting for the timeout (4096 fclk periods) instead of 256 fclk periods.  Do you have any other devices connected to the same SPI bus?

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    Prodigy 20 points

    Hi Bob,

    By setting SPIRST bit to 0 I do not observe this behaviour.

    There is only one ADC on the SPI bus.

    In the first screenshot I uploaded you can see that the last '1' on the ADC1_SDO line, coming from the ADC has half of the expected width, leading me to believe that the SPI interface goes into reset at that point.

    Regards,

    Konstantinos

  • 0 in reply to Konstantinos Vasiliou
    TI__Guru** 113765 points

    Hi Konstantinos,

    I should have looked closer.  The first screen shot you provided threw me off a bit with the placement of the timing marker.  I was looking at the transition edge and not the actual length of time.  At the point of the change of behavior the timing from CS going low to the change is approximately 20.4us which is the same as what would be expected for the SPI timeout for a setting of 256 *fclk periods.  So this does actually correlate with an SPI timeout and you have convinced me that is what is happening.  This is also verified by lengthening the timeout period (SPIRST = 0) having a successful communication.

    What is not clear to me is why this might be happening.  For some reason the timeout period begins correctly with CS transitioning low, however the SCLK is not idle during this time, so for some reason the internal timer is not being reset with the clock edges of SCLK.  I have not seen this issue before nor do I have any record of anyone else having this issue.  I would venture to guess that most applications would use a faster SCLK than you are using and would fit well inside the 256 * fclk window.

    At this point you could increase the timeout period by keeping SPIRST at 0 or you could use a faster SCLK to make sure that the data capture is always inside the timeout period.

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    Prodigy 20 points

    Hi Bob,

    I continued measuring and I figured that the SPI interface goes into reset when the phase between ADC1_CLK and ADC1_SCLK is the following:

    From the datasheet I assume that CLK and SCLK can be asynchronous

  • 0 in reply to Konstantinos Vasiliou
    TI__Guru** 113765 points

    Hi Konstantinos,

    I'm not clear regarding the point you are trying to make.  The master clock and the SPI clock can run asynchronously.  However there are some advantages with respect to reduced noise when the clocks are synchronized. 

    All that we know is that there are times the internal SPI reset timer is not reset even though there is an SCLK present (not idle high or low).  The maximum SCLK frequency is 1/(2*tclk).  So if the SPI timeout can be reset within 2 master clock cycles, it should certainly be able to within 8 cycles.  Regardless of if the phase is coincidental or not the timeout timer should reset relative to every change of phase of SCLK.

    Unfortunately I do not have access to the RTL code for this device so it is not clear how the logic works and why the timeout counter is not reset each time the SCLK transitions.  As I stated previously, you should use the default timeout which is greater than the normal conversion data read cycle, or use a faster SCLK so that all data are read within the timeout period.  I know that this does not specifically answer the question as to why this happens, but this is the first time in the history of the part that I'm aware of that someone has made this issue known.  The reason most likely as to why it has not been seen before is that the SCLK is much faster than you are using or the default timeout period is being used.

    Best regards,

    Bob B