ADS1258-EP: Wrong starting Index in shared configuration

Hi Anon,

Can you provide logic analyzer data showing the data transactions on all channels? If you have a Saleae analyzer you can send me the .sal file that will be easier to read than sending screenshots.

It will be helpful to see the DIN, DOUT, SCLK, and CS lines during the entire process (all measurements for both ADCs).

I also assume from the way you are reading data that you are not using DRDY to identify when new data are available. Is there any reason you do not use this pin, and instead have to keep reading the STATUS byte?

-Bryan

Unfortunately I don't have access to a Saleae, but can look into getting a few screenshots.

In regards to avoidance of DRDY, other designs that use my code (but not my design), do not use/have access to the DRDY pin. Because of the existence of the NEW bit as an alternative to DRDY, I figured this was an acceptable solution.

Hi Anon,

That is unfortunate about the logic analyzer, but let's see what you can provide. It will be challenging to diagnose this issue without being able to see exactly what is being sent to and received from the ADC.

It might also help to see a schematic. If you do not want to share this information publicly, you can hover over my user name until a dropdown appears, then hit "Request Friendship". This will allow us to share information via private message.

Using the STATUS byte is acceptable, but it would probably be easier to use DRDY (and would limit the traffic on the SPI bus since you do not have to constantly read/write the STATUS byte).

-Bryan

I can answer questions about what pins are connected to what, but I can't share the schematic.

I'd like to add on that it doesn't seem to be an issue with how the actual read is performed. I've verified that the CHID in the status byte is limited only to the channels I've configured. Similarly, the data that I read is exactly on-point with what I'd expect. The only issue is that the real index doesn't match my expectations around startup, and stays that way.

Hi Anon,

Maybe I am misunderstanding what the issue is then.

You said the data is as you expect - is that to mean that the data is valid but the CHID is not, or that the data and CHID are valid, but just not for the channel you expect to be on? For example, you have a 1V input on AIN3 and a 2V input on AIN4. When you expect to read AIN4, you are actually measuring 1V and the STATUS byte CHID bits = 0Bh (for AIN3)?

This is why it would be helpful to see the data transactions for all measurements, so that I can see what is being communicated to and from the ADC.

-Bryan

Data and CHID are valid, but do not match what I expect it to be on. Your example is correct. My code operates on a loop. 5 channels are enabled, with the intent to read it in the order of AIN0->3->4->5->6. Sometimes, this works. Most of the time though, on ADC1, it instead appears in the order of AIN6->0->3->4->5 (and always only in this order, I've never seen it start elsewhere).

I've checked on the oscilloscope and confirmed that the data and CHID match (so it's not the data getting read from the wrong channel or something). I've also confirmed that the order and configuration commands are correct (so there's no AIN7 getting read, or something outside what I've configured it for). I'm still working on getting startup waveforms, but it really just seems like, post-startup process described above, sometimes the index, instead of being set for AIN0 next, starts at AIN6.

Hi Anon,

To be honest, this sounds like a firmware issue, since the sequence is always off by only one channel. In other words, you never read channel data in a random order e.g. AIN3->5->4->0->6 and you never read channels you don't intend to read e.g. AIN7. Instead, you are always either starting with AIN0 (the correct sequence) or you are starting with AIN6 (which is incorrect, but then the sequence is correct starting with the next channel's data, AIN0). Without being able to see the firmware or the digital communication, I am not sure how much additional support I can provide. I would suggest reading back the registers after you have written them and make sure they are written as intended. You might also check the digital communication lines for noise using the scope.

On the other hand, does it matter in which order you read the inputs? I ask because if you are always reading the STATUS byte to check for new data then you always have access to the CHID bits. This way you always know which channel is being read, and therefore how to process this data in the firmware. And since the data seems to be accurate and valid for each channel, the only issue right now is the order in which the data is received. I recognize that this does not fix the issue at hand, but if the channel order does not matter then it feels like this might not be such an issue after all. Checking the CHID bits each time actually seems like a more robust solution because then you are always confirming which channel is being measured without having to rely on the ADC sequencer to loop through the channels (which could be affected by glitching / noise on the SPI, etc.)

Let me know if you have any additional information to share.

-Bryan

Hi Anon,

Thanks for posting an explanation of what you did, as well as letting us know that the issue is as resolved as it can be at this point.

I understand you may have sensitive information that you cannot share via this forum (or at all), but we would likely need to at least see the original firmware in order to help diagnose the source of this issue (assuming it is on the ADC side and not the controller). If you would like to pursue this path and discuss further with your local TI field representative, let me know and I can ask them to contact you.

If not, please feel free to post any additional questions in a new thread and we will support them there.

-Bryan