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

ADS1292R: Intermittent Malfunction After POR

young kyoo cho
Prodigy 20 points
Part Number: ADS1292R

Tool/software:

I am experiencing an intermittent issue after Power-On Reset (POR) where, during the initialization process in certain power cycles, the RDATAC opcode does not take effect or RREG returns all-zero values. However, even when this issue occurs, reading the registers at runtime confirms that WREG operations were always successful.

Here is my initialization sequence:

MAIN Board POWER ON
void init_ads1292r (void)
{
ADS1292R RESET HIGH : 1 s
ADS1292R RESET LOW : 100 ms
ADS1292R RESET HIGH : 100 ms
SPI transceive dummy 10 bytes with zero value
delay 10 ms
SDATAC (Stop Read Data Continuously mode)
delay 10 ms
configure ADS1292R
delay 10 ms
verify configuration (READ ADS1292R registers) ---> always OK
delay 10 ms
RDATAC (Enable Read Data Continuously mode)
START PIN HIGH
}

When this issue occurs, running init_ads1292r() again at runtime resolves the problem.
Also, although not yet 100% conclusive, my experiments suggest that the issue does not occur if no SPI communication (such as dummy data transmission) is performed before the SDATAC command during the POR initialization sequence.

Is it not allowed to transmit any SPI data before SDATAC after POR?
If that’s not the cause, what other possible root causes should I consider?

Thank you in advance.

Best regards,

Young

  • 0
    Prodigy 20 points

    That was my mistake.
    The line verify configuration (READ ADS1292R registers) ---> always OK is incorrect.
    In fact, there are intermittent issues during register verification as well.

  • 0
    TI__Guru 66316 points

    Hi Young,

    young kyoo cho said:
    Also, although not yet 100% conclusive, my experiments suggest that the issue does not occur if no SPI communication (such as dummy data transmission) is performed before the SDATAC command during the POR initialization sequence.

    After re-reading your initialization sequence, I was also wondering whether sending dummy bytes would create an issue - usually there is no issue with sending extra SCLKs after a register read/write command or during data transmission. What is transmitted on the DOUT pin during these 10 dummy bytes?

    Theoretically, the ADS1292R is expecting 9 bytes per frame (3x 24-bit words) during normal conversion mode. I would suggest sending either 9 dummy bytes, or none at all. What is the reason you are sending dummy bytes during initialization? As this step is not necessary, I would suggest simplifying the routine and removing this step.

    Again - I would also suggest reducing the RESET-LOW time after power-up since you are not giving a proper reset pulse (as we discussed in your previous thread). :)

    Regards,

    Ryan

  • 0 in reply to Ryan Andrews
    Prodigy 20 points

    Hi Ryan,

    As mentioned in the previous thread, reducing the reset pulse width to 1 ms did not eliminate the issue.
    Experimentally, I found that if I add a 1 ms delay between nCS LOW, SPI transceive, and nCS HIGH during the initialization sequence, the issue no longer occurs.
    As a result, both the previously reported RDATAC command failure and the RREG read failure described in this thread are no longer observed.

    After initialization, when receiving ADS1292R data continuously, the same short delays (about 11 us) can be maintained without any problems in data reception.

    Regards,

    Young