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.
I'm trying to read out the ADS7863 by the McBPS of a C28346.
Now I am confused about a timing issue that is pointed out in the manual. I am referring to the data sheet of the ADS7863 from January 2011.
I connect both CONVST and RD together, and this signal is generated by the MFSXA signal of the McBSP.
On page 8, there is a timing characteristic, telling me that CONVST has to rise 10ns before or 5ns after the rising clock of CLOCK.
But on page 15 under CONVST, the document points out:
RD (read data) and CONVST can be shorted to minimize necessary software and wiring. The RD signal is triggered by the ADS7863 on the falling edge of CLOCK. Therefore, the combined signals must be activated with the rising CLOCK edge. The conversion then starts with the subsequent rising CLOCK edge.
Now this sounds like I can toggle the CONVST/RD signal syncced to the CLOCK signal?
When I look at the timing diagram of the PSEUDO-DIFFERENTIAL MODE II on page 26 (the mode I use) it also looks like these signals are in sync, though the scale there is too small to see it clearly.
The problem is, I cannot shift the MFSXA signal of the McBSP, it always toggles the same way as the CLOCK does. At least I wouldn't know that there is a way.
Could anybody help me in this matter?
Thanks for your question on the ADS7863! This is something I've helped others with in the past on the earlier versions of this device like the ADS7861 and ADS8361. The CONVST and RD inputs do need opposite edges of the SCLK to get everything synced up properly.
As you know, the FS of the McBSP pulse goes active on the same edge that would be considered the 'driving' edge of data (in or out). You should be able to configure the FSYNC for the C28346 as an active high pulse that is 2 SCLKS wide. DOUT from the ADS7863 is valid on the falling SCLK edge. Assuming FS is going high on the RISING clock edge, RD will be validated on the falling edge following FS rising and CONVST will be validated on the rising edge under FS high. Set your data receive in the McBSP for a 1-bit delay and you should be able to properly read the conversion results from the part.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Tom Hendrick:
Thanks for your answer, which is very appreciated!
I struggled to make the FS two SCLKS wide, until I found out that I had to set the FSGM bit for the FWID setting to take effect. This in case had the unfortunate effect, that the FS pulses are now produced always, not only when I send data to the bus. I didn't find a way to prevent that.What I try to do is reading out the 6 channels once every millisecond. If the FS pulses are generated all the times, it is difficult to get in sync with the ADC again. I would have to find out if the ADC is the first or the second phase of the conversion/transmission of a data pair.
So I thought I help myself by toggling the CS signal with a GPIO line.Now I disable the FS signal with the FRST bit in idle. As soon as I want to start the transmission, I enable the CS, then I enable the FS signal and send the data.This somehow works, but it is not predictable if the ADC starts at the first or at the second FS signal. That's what I don't understand why. See the two following screenshots.
1 yellow: The busy signal2 blue: The CS3 red: Clock4 green: FS
You can see that in the first case, the busy signal goes high right with the first FS signal. In the second case, it goes high with the second FS signal.Why is that? This makes it very hard for me to get in sync with the conversion/transmission.
Sorry for the long text. I am struggling with that interface the whole week already. It's somehow harder than it looked at the first sight.
Regards from SwitzerlandDaniel
In reply to Daniel Haslimann:
No issues at all with the long text!
It looks like you may be ending one set/starting another set of conversion cycles at different times, causing the BUSY to vary. The McBSP running under FSGM control might be the culprit here especially if a GPIO is controlling /CS. Take a look at this app note:
While written for a different processor than what you are using, it explains how to sync up the ADS8361, which is an early version of the ADS7863 as I mentioned in the earlier post. You should be able to sync up the ADS7863 in much the same way.
Thank you very much for your support. The document helped me to get it running.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.