• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 46 subscribers
  • Views 562 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.

Original question:

ADS7953: Data errors?

ADS7953: Startup failure

Javier Vara
Expert 1645 points

Part Number: ADS7953
Other Parts Discussed in Thread: TMS570LS1227

We are using an TMS570LS1227 to interface over one SPI with two devices, one of them ADS7953 (each with its own CS line). We have the system up and running and it has been working fine for a while now, but the customer first reported an issue about 2 months ago and has reported another instance of the same last week, so I am looking into it. The issue happens at startup, but it only ever happens very very rarely, 99.9% of the time works fine. Also, I should say that the 2 times it happened, it was only solved after power cycling the whole system. In all cases, if the device started without the issue, then it carried on working without problems.

Our normal sequence at startup is: we send a reset command, then get the device into auto mode 2 and from there simply toggle the CS line ( data to ADS = 0) and read the channels data with the ID. This data is used in some safety functions that would trigger a fault if wrong data is received. This is what happened the 2 times so far this issue has been triggered. Of the first incident I don't have much data. After that, I gave the customer some special version of the fw that would allow us to know what the micro is reading from the ADS instead of just triggering the fault. When the second fault happened we saw that we are reading 0x3FFF data back from the ADS all the time. Given that this is not 0xFFFF (something got stuck high for example), to me it looks like the ADS was not configured properly in auto mode 2 (as per our startup sequence), but rather it got stuck in manual mode and reporting all the time channel 4 (first 4 bits is the ID). It also looks like the voltage range was not selected correctly (again as part of the startup) since we use 5V. Channel 4 should sit around 4.5V, so if the voltage range wasn't configured correctly either, we would be reading 0xFFF. This is my theory behind why we are reading 0x3FFF. Somehow the startup sequence got messed up leading to the device stuck in the wrong mode and configuration.

I have seen another 2 posts with similar kind of issue but without answer:

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/941973/am3352-unwanted-signals-on-spi-line-during-power-up?tisearch=e2e-sitesearch&keymatch=ADS7953#

https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/933197/ads7953-data-errors?tisearch=e2e-sitesearch&keymatch=ADS7953#

Some questions:

- Given that the SPI link is shared with another device, is it possible that at startup it is mistakenly reading some data that is going to the other device and this data is getting the ADS stuck in a state that it cannot come out from later? During our power up sequence first command send is 0x4200, which should reset the ADS, so the rest of the configuration goes through correctly. My understanding is that, even if there was some spurious data being read by the ADS because of this, after sending the reset command it shouldn't matter?

- I have scoped the power-up sequence. In our board VA and VBD come up at the same time. It turns on for 5ms, then turn off (something to do with the micro bootloader), and then about 200ms later it turns on again and stays. During the turn-on VA is always higher than VBD, but I have noticed that when it turns off, the VA rails turns off faster than the VBD, and VBD is higher than VA for around 10ms while it turns off. Is  this ok? Could this affect the device so when it powers up after the 200ms it might be in an unknown state?

-The device doesn't have any kind of state registers where we can read if it has correctly gone through the configuration and running in the mode we want it. Is there another way to detect this condition? And if we did, could we just rerun the startup sequence to get it to the right state?

- Any other idea of what might be going on?

  • 0
    TI__Mastermind 29198 points

    Javier,

    1. The fact that you are doing a reset before configuring is a good idea.  I am surprised that following the reset you still have the device in a strange mode.  Have you confirmed that the supplies are up and stable before the reset is sent?  Do you think there may be a transient on the supply that puts the device into a strange mode?  If the device gets into the strange mode can you try to send the reset again and see if it gets out of the bad mode.
    2. Regarding your questions:
      1. Is it possible that at startup we you are reading another device? This seems unlikely to me but not impossible.  I assume that you have a separate chip select for every different SPI device sharing the bus.  Correct?  If so, it is unlikely that any device would try and talk if it’s chip select isn’t active.  I agree that the reset should get the device out of the strange mode.
      2. I have scoped the power-up sequence. This is exactly the type of test I would ask you to make, so I think you are potentially on the right troubleshooting track.  As you must have noticed, the data sheet indicates that VA >= VBD.  I think it is possible that the device is getting into a strange state because during the power down VA drops faster than VBD.  Can you increase the 200ms delay?  It is possible that internal nodes and/or the decoupling is not fully discharged by the time the 200ms is complete.  When you monitor the supplies, do you look directly on the device decoupling?
      3. The device doesn't have any kind of state registers. Unfortunately, you are correct.  This device does not have traditional registers where you can read them back and confirm the setup.
      4. I have contacted Cynthia (author of the other post) to see if she has any insight into the issue.
      5. Other ideas. How do your digital communications look.  Do you have a lot of noise, or overshoot in your digital signals.  Basically, I am just asking to check and see if this is a possible data integrity issue.  Data integrity issues can put devices into strange modes.  This problem can usually be mitigated by sending a reset command.
      6. Other ideas. Do you think you can do something to make this issue happen?  It’s going to be difficult to reproduce or resolve if the problem is very infrequent.  Perhaps you could try and reduce the 200ms delay or do something to make the power supply sequencing worse.  I’m not sure that the supply is the problem, but this is probably a good starting point. 
      7. Other ideas. Is your BDGND and AGND connected to a solid GND plane?  This is what we recommend.  I have seen this kind of issue in the past (different device) where people use separate analog and digital GND (connected via a ferrite).  We do not recommend using a ferrite to connect to GND planes together.  I general we do not recommend separate grounds but definitely do not connect ground via a ferrite. 

    These types of intermittent issues are hard to solve.  I hope some of my comments above help.  Let me know your thoughts.

    Art

  • 0 in reply to Art Kay
    Expert 1645 points

    Art,

    Thanks for the quick response.

    1. Yes, I can confirm the supplies are up and stable before sending the reset command. Also, yes we are considering adding an extra step as part of the configuration where, if we read back erroneous data, we would trigger re-configuration of the device (including reset command). I was leaving this as the last option as it doesn't really address the root cause of the issue but rather just works around it.

    2.

       a. We have separate CS yes for each device. I'm currently looking into the possibility that maybe the ADS CS line is toggled erroneously at startup. Not sure on this yet.

       b. Regarding the drop in voltage and power back up. I have looked into it and it turns out this was wrong. It was an artefact of the bench power supply I was using for the PCB (hitting overcurrent and turning off the rails temporarily). With a better supply there is no such drop. In the customer's application I cannot guarantee that a similar thing happens but I cannot discard it either. It is a little bit difficult to get the customer to measure this kind of things but I might have no other option but ask them if we cannot figure out what is going on.

       e. Communications look good an stable. We are running only 1Mbps, so not very high speeds either, I have scoped the signals and I don't see any ringing or similar.

       f. I am looking into setting up a system to continuously power cycle the PCB and look for the issue happening so we can trigger the issue in-house. This will probably take a couple of days to setup at least.

      g. Yes, GDGND and AGND are connected together to a solid ground plane

  • 0 in reply to Javier Vara
    Expert 1645 points

    also, one more thing. We are currently using the ADS in auto mode 2, so it would cycle automatically through all the channels. I'm wondering if it would be safer to use manual mode and manually cycle through all the channels. Since in every frame we have to send the mode, channel, range, etc. Even if one cycle didn't work for whatever reason, it wouldn't get stuck in manual mode like it happened for our customer. It will always cycle through all the channels. What do you think?