CCS/EK-TM4C1294XL: Problem of reading 32 bit length SPI data from the ADS127L01 ADC board.

Quickly - it is believed that the MCU's 'FSS' pin must be 'driven low' - even when the MCU is declared 'Slave.'    You note that you have likely a, 'No connection' to FSS.

Your review of sample code (SPI MCU as Slave) will confirm this belief.    You may wish to note that 'multiple Slaves may be present' - and it is 'Only the FSS pin driving low' which enables the selected, 'Slave MCU or device' - to recognize itself as the intended, 'data recipient.'     (in your case there is only one Slave - yet that is 'outside' normal/customary usage!)

The ability to 'receive a 32 bit SPI stream - to my belief - (may) not be possible due to the MCU's specified, '16 bit SPI data capacity.'    (I believe that can be 'overcome when transmitting' by 'manually controlling (i.e. extending the FSS pin's active time) but (possibly) NOT when receiving (as the ADC dictates the FSS/CS signal's duration...   

Unless & until you can:

• capture the initial 16 bits from the Master
• and then (somehow) capture the additional 16 bits remaining.   

Your success appears (somewhat) in question.

Is it possible that the ADC can be directed to:

• 'Hold-Off Transmission' (post the first 16 bit ADC data capture - by your MCU?)
• And only after those  initial 16 ADC bits have been captured by the MCU - direct the ADC to send the remaining 16 bits?

It is proposed that the MCU 'Command the  'ADC Master to (first) halt (post the 1st 16 bits transmitted) and to only 'continue' - once those initial 16 bits have been safely stored!    (such an approach counts heavily upon 'Wishful Thinking' - yet this method offers (some) hope...   maybe)

Hi cb1, Mete,

  I'm not familiar with the ADS127L01, Reading its datasheet, it can operate in either SPI mode or Frame-Sync mode. I think the Frame-Sync mode corresponds to the TM4C129's TI synchronous mode while the SPI mode is the standard Freescale SPI. The frame-sync mode asserts the sync pulse before the serial data begins while the SPI mode holds the chip-select active during the serial transmission.

  The TM4C129 can only receive max of 16 bits of serial data, I'm not sure if the ADS127L01 can break it into two different 16-bit transactions as suggested by cb1. Since I'm not an expert in ADS127L01, I will suggest you open a question with the Data Converter Forum. 

Hi Charles,

Staff/I are 'so glad' that you've confirmed (our) belief that your MCU can accommodate 16 SPI received bits, maximum - unless (highly special) adaptations are made.

Now we made 'no effort' to review poster's ADC data sheet (he could have helped himself by presenting several 'key data scans') thus we 'matched' that 'non-effort/helpfulness.'

Having a bit (20+ years) more experience than young staff - I told them that it would have been 'Clever & Helpful' - had the ADC 'recognized the inability of many/most MCUs - to accommodate a 32 bit, SPI received, data stream.     It was 'under that belief' - that I devised the, 'Divide & Conquer' approach (i.e. two 16 bit SPI Data Chunks) - earlier presented.    Not much hope - beyond that...

While a 'pity' - it IS possible to resolve that (long SPI) data stream via, 'Bit Banging' - yet the many efficiencies the SPI Peripheral presents - are then 'Lost.'    Any such '24 bit ADC' is 'Big Time' - must be superbly handled & treated - and (may) prove 'over-kill' - especially as the (apparent) Data Mismatch - has been 'missed.'

Should it be noted that, 'Prior to choosing devices' - all capabilities should 'reasonably' match?    Discovering conflict - late in the game - is never pleasant...

Hi Charles,

That's terrific - and guess what - as (one suspected) there ARE 2 - 16 bit ADC Data Chunks!   

Assuming that a, '32 bit SPI Reception was possible' (or its bit-banged equivalent) one could:

• count the 'SClks'
• and then strategically, 'intercept & flip' the ADC's 'FSync' - just post Bit 16.

Yet - there appears an EVEN MARKEDLY SUPERIOR MEANS TO ACHIEVE THIS!

• Invert 'FSync' and feed that - along w/'SClk & DOut' to, One of the MCU's SPI Modules.   (this captures ADC Bits 31-16)
• Feed the 'non-inverted' (original) 'FSync' - along w/'SClk & DOut' - to  Another of the MCU's SPI Modules!    (and this captures ADC Bits 15-0)

Such IS Magic - is it not?

• complies w/the MCU's 16 bit Max, SPI Reception Capability
• enables the ADC Master to output 'normally' (as the ADC designers DID 'Follow cb1's earlier prescription' of, (chunking data into 16 bits!))
• upon the reception of the final 16 ADC bits - the data (from the 2 different SPI Channels) may be combined - and processed as needed!

It may be required to 'flip the edge' of 'SClk or DOut' - that level of detail left to the poster...

What do you think, Charles?    And somehow - *** LIKE *** remains (improperly), 'Kicked to the Curb!'

Hi  Charles , cb1,

Thank you for your valuable interpretations and recommendations.

As a result of all the information that we have obtained, We decided to stop working on this two incompatible boards. 

ADS127L01 EVM   and  EK-TM4C1294 

Subject of Incompatibility : SPI transactions

Problem : data length and frame sync mode.

Our purpose:

1- To convert an analog voltage data to binary numerical value with 24 bits of resolution.

2- Transfer the ADC numerical output to a micro-controller with a fast, continuous and lossless way.

3- Process the data in the controller with the addition of other process variables to obtain new (output) variables: operations  such as filtering ,

various mathematical  and logic operations.

4- Transfer the resulting variables to another control system by the way of an CAN , Ethernet , or one of well-known  communication channels.

 to obtain new variables

 May you suggest a compatible ADC and micro-controller pair , which satisfies the above-mentioned purposes?

Short info about our projects:

 Our project is about measuring and evaluating the inertial measurements such as gyrometer, accelerometer, position encoder, speed measurements.

We are using another TM4C1294XL to read only position and velocity data. Four angular position encoders connected to our uC with CAN bus.

But we don't need to finish everything in a single chip. We want to process raw values in discrete hardware blocks . After that, we want to

put them together by transferring them towards  a final control unit,  utilizing some proper communication ways (i.e. Can bus) .

We asked the similar question in the "E2E Data converters Forum" under another title, as you suggested before.

Thanks again and Best Regards,

Mete

Hello,

While my group is 'without' your specific ADC (and/or its board) - my post of (15:41, 25 Nov) above - may well have, 'Resolved the incompatibility between ADC & MCU.'    

Follows now a repeat of my (proposed, yet untested) resolution:

Yet - there appears an EVEN MARKEDLY SUPERIOR MEANS TO ACHIEVE THIS!   (Mating of ADC & MCUs differing SPI formats)

• Invert 'FSync' and feed that - along w/'SClk & DOut' to, One of the MCU's SPI Modules.   (this captures ADC Bits 31-16)
• Feed the 'non-inverted' (original) 'FSync' - along w/'SClk & DOut' - to Another of the MCU's SPI Modules!    (and this captures ADC Bits 15-0)

Such IS Magic - is it not?    (my arm proved - 'just long enough' to reach - then pat - my back)

• complies w/the MCU's 16 bit Max, SPI Reception Capability
• enables the ADC Master to output 'normally' (as the ADC designers DID 'Follow cb1's earlier prescription' of, (chunking data into 16 bits!))
• upon the reception of the final 16 ADC bits - the data (from the 2 different SPI Channels) may be combined - and processed as needed!

It may be required to 'flip the edge' of 'SClk or DOut' - that level of detail left to the poster...

Indeed (some) 'monkey  motion' (unkindly) or 'inspiration' (kindly) was required to, 'Bridge the data formatting 'gap' - between ADC & MCU.'   

It appears that you are in possession of 2 boards - thus only the addition of a suitable (fast, 3V3 level, hex inverter) along w/close-in locating of boards & short/direct wiring between each board - is required to, 'Implement this approach.'    (should only the ADC's 'FSync' require inversion - a 'tiny' sot device may be employed)

It is suspected that such 'Big Gulp' (i.e. ~32 bit) ADCs will 'normally' attach to high performance FPGAs or SOCs (system on chip) - as most MCUs prove, 'Not up to task: 32 bit, SPI (Slaved) Reception Challenge!'

Hi Charles/CB1

Another poster has 16 bit issue when 32 bits are desired. Seems very doable as it was with the UART 16x8 FIFO. Only required correct internal peripheral timing to achieve. Perhaps the FSS flag can be used with one TM4C1294 to indicate the binary split as CB1 diligently points out. So the FIFO and SW must have similar transport to seamlessly digest the ADS127L01 full 32 bits. Does it not seem very wrong that a 32 bit MCU could not handle 32 bits from the outside world? I believed it possible and was correct in the end but it did require some minor FIFO finesse to obtain and re-assemble 32 bits.

The TM4C1294KCPDT QSSI modules have the following features:
■ Four QSSI channels with Advanced, Bi- and Quad-SSI functionality
■ Programmable interface operation for Freescale SPI or Texas Instruments synchronous serial
interfaces in Legacy Mode. Support for Freescale interface in Bi- and Quad-SSI mode.
■ Master or slave operation
■ Programmable clock bit rate and prescaler
■ Separate transmit and receive FIFOs, each 16 bits wide and 8 locations deep
■ Programmable data frame size from 4 to 16 bits
■ Internal loopback test mode for diagnostic/debug testing
■ Standard FIFO-based interrupts and End-of-Transmission interrupt
■ Efficient transfers using Micro Direct Memory Access Controller (μDMA)

Perhaps it not so difficult to gather 32 bits via two 16 bit frames.

Datasheet reveals SSIO registers are somewhat similar to UART 16x8 FIFO behavior. Seemingly SSISR registers RNE flag can SW monitor and force wait state after 15:0 data chunk has BUFFERED while SSIDR then loads data chunk 31:16 from SSIO 2nd 16 bit frame.

Some part of FSS flag derived from R/W control logic must trigger RNE flag every 16 bits, FIFO empty follows FSS signal input state changes?

BP101 said:

Seemingly SSISR registers RNE flag can SW monitor and force wait state after 15:0 data chunk has BUFFERED while SSIDR then loads data chunk 31:16 from SSIO 2nd 16 bit frame.

Amigo,

Had you 'missed' the fact that poster's ADC (NOT the MCU) is the SPI Master?     How then can the Slave MCU ...  force any wait state?   (unless the ADC provides (some) mechanism to allow/enable that?)

The 'original' method I described - employing two of the MCU's SPI Modules -  each one capturing a '16 bit chunk' of ADC data - imposes no such 'Wait Requirement' upon the ADC Master!

It is certain that many here would 'love' to learn - 'How & Why' you achieved, "... Some minor FIFO finesse to obtain and re-assemble 32 bits."    The mere representation - minus ANY strategy/guts - proves not too useful...  

Dear Cb1_mobile,

I have to admit that I have some difficulty in understanding the literary writing language you use.

I use "google translate" to understand. I imagine you're a clever and humorous person.

You have offered us a great solution, so I want to thank you once again.

Before applying this recommendation immediately, we decided to stop. We wanted to investigate if there are any other alternatives.

The reason behind this is that there is no single ADC that we want to connect to our "micro-controller" via SPI.

"micro-controller" may require all SPI channels to use, there are multiple devices we want to communicate.

The idea of ​​using two SPI channels for a single ADC pushed us to think a bit. Because it's a little different from what we had planned.

We, as a newbie team, have to wait for different suggestions from you.

Now, I am especially looking forward to the next answer from the "Data converter forum".

Best Regards.

Mete

cb1_mobile said:

The 'original' method I described - employing two of the MCU's SPI Modules -  each one capturing a '16 bit chunk' of ADC data - imposes no such 'Wait Requirement' upon the ADC Master!

Yet even harder to vision SW to recombine BUFFER contents from 2 uniquely named storage arrays opperating independently besides other timing issues that may present. The wait of FSS transition is viewed from the TM4C SW perspective, not the slower master SIO. The SW can do NASCAR donuts around the SSIO input FIFO.

quote: Some part of FSS flag derived from R/W control logic must trigger RNE flag every 16 bits, FIFO empty follows FSS signal, input state changes?

Hello back,

Glad you've accepted our suggestion - staff should have a schematic 'here for you' by 'noon, CST (Chicago) tomorrow.'

We do ask - that to 'reinforce your group's learning' - that you study the 'ADC's Data Transfer Timing Diagram' (which vendor's Charles so kindly provided) and attempt to (best) 'mate that' to the 'most appropriate of the MCU's SPI Data Formats.'    Do show your results - we will do the same.

Thursday here is a 'Big US Holiday' - yet we've had a 'great Sales year' - and at least, 'Half of our crüe' will 'Show Up' (at least for a half day - so that we may (almost) catch up!)    Our hope is that you can 'implement' our simple schematic on 'Thursday' - so that we can review it w/you by this Friday.

Green resolve without any evidence or experiment how dual SSIO will even work in software leaves me bewildered in the silence of vendors suggested answer.

Vendors silence how 32 bit MCU can not easily handle 32 bits from the outside world even more disturbing!

How do you plan to resolve the first frame from overlapping the second in the recovery buffer? Have you even considered the complexity of handing not 1 but 2  FIFO interrupts that may or may not pend at the same NVIC priority? Your jump to rapidly suggested green solution does not blow KISS right out the window?

Best of luck trying to untangle 2 receive interrupts in tandem and keep buffer pointer aligned with serial FIFO data. Has not the propensity for unexpected results gone from 50% to 100% by adding a second SSIO?

user5151893 said:

ADS127L01EVM: Is it possible reading "32 bit SPI data output" from the ADC to MCU - TM4C1294XL

https://e2e.ti.com/support/data-converters/f/73/t/860277

That was an arbitrary unconfirmed answer by the poster, never to confirm such was even possible or how the TM4C1294 can receive 32 bytes by a single 16x8 FIFO let alone two FIFO's. The first 16 bytes are easy to buffer, the second will en-vole a SW challenge the vendor did not comment upon.

Perhaps busy bees could do an experiment and report the difficulty truth to this forum.

Greetings Mete,

Staff & I have made more 'Key Findings.'     It proves best to send these via the Forum's 'PM' capability.     Kindly, 'Go to your 'forum sign-in page' - and (after some search/scrolling) click on the, 'enable conversations' option.    Once completed I can send you drawings & more complex Tech detail.

Hi  BP101,

Thank you for your interest , interpretations and suggestions to our SPI communication  problem.

Now we have got an answer from Data-Converter forum .  Mr. Keith Nicholas and Mr. Ryan Andrews from "Precision ADC" have found the cause of problem.

The ADS127L01 EVM  can only support "SPI mode".

Does not support:   Frame-sync master mode or Frame-sync slave mode.

We did not noticed the abovementioned information while reviewing the user manual of ADS127L01. Because of this carelessness, things got a little longer.

As shown below, the data is transmitted in 8-bit packets, figure is taken from the  data sheet of ADS127L01.

But, It is necessary  to use a common clock source for both devices.  So we need to find an external clock input pin on the TM4C1294 board.

As recommended, CLK source is in the ADS127L01. It is a 16MHz clock. We have to connect this signal to  an external clock input of TM4C1294.

At first, we couldn't find a proper place in the EK-TM4C1294XL.

This was the reason that forced us to choose Frame-sync. mode. Because it does not need a common clock.

Unfortunately Frame-Sync mode is not supported by ADC side .

You can see the detailed description in the        https://e2e.ti.com/support/data-converters/f/73/t/860277. 

Hello cb1_mobile,

I will do this . But I want to inform you about new events.

Now we have got an answer from Data-Converter forum .  Mr. Keith Nicholas and Mr. Ryan Andrews from "Precision ADC" have found the cause of problem.

The ADS127L01 EVM  can only support "SPI mode".

Does not support:   Frame-sync master mode or Frame-sync slave mode.

Actually in the ADS127L01 EVM  board there is already a TM4C1294NCPDT micro-controller and it is communicating with ADC chip via SPI. But the mode of it  :  SPI Mode ( Freescale SPI mode)

We did not noticed the above-mentioned information while reviewing the user manual of ADS127L01. Because of our carelessness, things got a little longer.

As shown below, the data is transmitted in 8-bit packets, figure is taken from the  data sheet of ADS127L01.

But, It is necessary  to use a common clock source for both devices.  So we need to find an external clock input pin on the TM4C1294 board.

As recommended, CLK source is in the ADS127L01. It is a 16MHz clock. We have to connect this signal to  an external clock input of TM4C1294.

At first, we couldn't find a proper place in the EK-TM4C1294XL.

This was the reason that forced us to choose Frame-sync. mode. Because it does not need a common clock.

Unfortunately Frame-Sync mode is not supported by the ADS127L01 EVM.

You can see the detailed description in the        https://e2e.ti.com/support/data-converters/f/73/t/860277. 

The case described in detail to the "Data-Converters-Forum"  by a member of our team - his name is Riza-  who is responsible from this application.

I apologize for misleading you.  So we better freeze your 'Dual SPI ModuleTechnique' temporarily.

Now we need some more help to overcome this clock issue.

Best Regards,

Mete

Hi,

I am in my house now. Because of time difference now It's 22:30 in our place. For online conversation, I must be in the company in our laboratory .

As the manager of R&D department, I  want some of my teammates with me. Especially the person responsible for this application have to be there. 

I's necessary to make a plan for night work.

(I haven't slept properly since two days already)

Thanks and Best Regards,

Mete

Hi,

  Earlier I mentioned to you to consider using the SPI mode. It is just one alternative in addition to cb1's great idea. With the normal SPI mode, you can configure the MCU SPI to read two 16-bit data. From the MCU point of view, it is seeing two sets of 16 SPI clocks as two different frames. You may need to enable the Fss Hold feature although I don't think it is absolutely needed when operating as a slave. I'm not here to say which method is better than other. I think you and your team can decide what is most suitable. 

Hi,

You are right.  Now, we know that the "Freescale SPI mode" is the only way of SPI communication. 

But,  on the  EK-TM4C1294XL board, where will we connect the 16MHz  clock source from ADS127L01?

Best suitable place seems to be OSC0 (pin88) of MCU. But there is already an 25MHz crystal between the OSC0 and OSC1.

Is it correct to remove the crystal  and link the  pin88 of TM4C1294NCPDT to the ADS127L01 evm board's clock source?

What is your suggestion?

Best Regards,

Mete

Hello,

I like to apologize for thinking 32 bytes buffer versus 32 bits above but even so 16x8 FIFO had me rattled.

Your 16Mhz clock connect to SSIOCLK input?

user5151893 said:

Unfortunately Frame-Sync mode is not supported by ADC side .

Sorry - absolutely it IS!    

Direct quotes - gleaned last night from the device's 89 pg. manual:

• "A variety of operating modes allow for optimization of speed, resolution, and power.   A programmable serial interface with one of three options (SPI, frame-sync slave, or frame-sync master) provides convenient interfacing."    Note that vendor's Charles was first to discover & present this.
• Indeed SPI Mode (as noted above) is an option - yet it may not prove 'ideal' (at all times) for your particular application!     That is the 'very reason' why Three Options (SPI & TWO Frame-Sync) are (cleverly & importantly) provided.    And do note - the 'Frame-Sync options' outnumber the other!    (there must be some reason - don't you agree?)

Here - directly from the device's manual - is confirmation of Frame-Sync Mode (Master) - very much being 'Supported.'

and

Frame-Sync Mode is a powerful method w/proven advantages.    'Mating this timing chart' (above) to your (and most other MCUs w/out 32 bit SPI (single gulp) capabilities - requires: Indirection, Resourcefulness, & some Cleverness -  as earlier (one here) detailed...

Hi Cb_1,

Frame- sync. mode is that  we have  used with this system already. The chip performs this. But it is not so-called "Freescale SPI".

At the other hand, in Evaluation Module's User Manual , it is clearly described  in page -4  as follows:

user5151893 said:

But,  on the  EK-TM4C1294XL board, where will we connect the 16MHz  clock source from ADS127L01?

Best suitable place seems to be OSC0 (pin88) of MCU. But there is already an 25MHz crystal between the OSC0 and OSC1.

Is it correct to remove the crystal  and link the  pin88 of TM4C1294NCPDT to the ADS127L01 evm board's clock source?

I'm really confused with your question. Why is there a need to connect anything at all to the MCU's OSC pins? If the ADS127L01 needs a master input clock then you need to provide this 16MHz clock to the ADS127L01, not to the MCU.

Hello,

The system clock of  TM4C1294  and  ADS127L01 must be the same, and it is an external source in the ADS127L01 board, in order to remove any clock intermodulation artifacts from the ADC spectrum.

In the EVM ADS127L01 evaluation board, there is a TM4C1294NCPDT chip and ADS127L01 chip. But their clock sources are same and external. 

In the EVM ADS127L01 board, the external clock (16Mhz) is connected to the OSC0 (pin88) of the TM4C1294NCPDT chip.

Best Regards,

Mete

user5151893 said:

Frame- sync. mode is that  we have  used with this system already. The chip performs this. But it is not so-called "Freescale SPI".

Pardon - but may staff & I ask, "So What?"   Is it not 'likely' that via the (earlier suggested) possible, 'flipping of strategic SPI bits' - along w/the 'necessary & inspired' employ of that 2nd SPI Module -  that the 'Frame-Sync Master Mode interface can succeed?'

You only recently have provided the detail of the ADC's Eval Board!     The 'solution' I proposed was (my usual) 'General, Broad-Based Attempt to Identify a, 'Solution Method.'    (which most always - better serves the forum community!)    Note that you had 'failed' to 'advise and/or inform' of the (newly introduced) requirement to, Adapt to your existing board - which (already contained the '129 MCU.)    

My method was based upon:

• Vendor's Charles resourceful 'find & presentation of the ADC's Timing Chart' - when placed into Frame-Sync Master Mode.
• My understanding of the '129's SPI capabilities - especially the challenge of receiving that '32 bit continuous SPI Data Stream from the ADC!'
• Your postings - coupled w/Charle's input - provided my (only) 'understanding of your chosen ADC' - as I 'worked for the required, 'outside the lines' (i.e. unusual) solution.
• It may be noted - that several years past - I co-authored several Tech Papers appearing upon MIT's site - dealing w/'Efficiently Processing Long Streams of Serial Data' - and that past work, 'advised & informed' (maybe 'mirrored') my contribution in your behalf, here. 

This ship has now sailed - staff & I wish you success...

Hi Charles,

You say, there is no need a clock connection between host and devices. Clocks are being  independent as it can be seen in the figure.

If it is right,  we are Ok.

It has to be so. ADS127L01 EVM has its own clock. MCU also has its own clock. They don't need to be synchronized.( Serial clock is being shared already).

It makes sense. 

Thank you , I hope this will resolve my issue.

I will let you know as soon as the test is over,  tomorrow.

Best Regards,

Mete

Hi Charles,

I hope, the below written information will not  occur.

Earlier, when we first implemented this system, we saw very noisy waveforms in the oscilloscope.

We will see tomorrow.

Best Regards,

Mete

user5151893 said:

It has to be so. ADS127L01 EVM has its own clock. MCU also has its own clock.

Why not simply use an PIOSC alternate clock source on SSIO peripheral if that becomes an issue, so the MCU still uses 25Mhz XTAL. If you need 16Mhz external clock perhaps the DIVSCLK output pin can use PIOSC but asynchronous to MOSC. Seemingly that should not matter if Master provides the SSIOCLK input.

Hi BP101,

Thank you for your suggestion. I'm gonna go check it out and get back to you.

Best Regards,

Mete

Hi Charles,

Today we  have made the SPI interface connections that you suggested, which we already want to make, as shown in the Data-Sheet Figure 103.

Host MCU  TM4C1294XL sends 8-bits length data accompanied by SCLK(serial clock).

Although the ADC periodically sends a Data ready (DRDY) signal, it does not emit any signals from the DATA OUT (DOUT) terminal. Maybe it's because host doesn't continue to send SCLK signals. 
While the Host MCU sends a signal to the ADC, it also sends SCLK pulses. However, when it comes to receiving data, the ADC does not send the transformed result because the SCLK pulses are interrupted. If we apply 4Mhz SCLK from another source it is sending.

I attached below the oscilloscope screen-shots . The first picture is zoomed in and the second one is zoomed out versions of same screen.

The text at the end is the example program which  we used (modified a little).

Now (example program which is running in the host) can send 8-bits data. But ADC does not answer. If we connect an 4 MHz clock to the SCLK pin on the

ADS127L01 board then it starts to send data . Why the Host MCU doesn't continue to send SCLK .

Attached figures :

The first and second pictures are zoomed in and zoomed out versions of the same oscilloscope  screen.

The text at the end is the example program which  we used (modified a little).

Can you make a comment about this problem?

Best regards,

Mete

Hello,

  You are giving very conflicting information and I'm really confused. Perhaps you should answer some key questions before we proceed. 

  1. In your very first post you wrote the below. You said the EK-TM4C1294XL will be the slave. As a SPI slave, it will never generate SPICLK. Only master generates SPICLK. So who is the master? Up until now, at least I'm under the impression that your ADC EVM board is the master who will be sending out the SPICLK to the EK-TM4C1294XL launchPad. Now in your latest post you wrote 'Although the ADC periodically sends a Data ready (DRDY) signal, it does not emit any signals from the DATA OUT (DOUT) terminal. Maybe it's because host doesn't continue to send SCLK signals. ' Who is the host? I assume you meant the EK-TM4C1294XL launchPad as the MCU host. 

ADC Board is the SPI master: Texas Instruments  EVM ADS127L01

Selected Master SPI mode  : Frame sync mode   .   EK-TM4C1294XL will be the slave. It will not send any data . It will only read.

Used SPI outputs of the ADC board (master)  :  SCLK, FSYNC, DOUT .

  2. Is Pranav Deep your colleague who created this post https://e2e.ti.com/support/microcontrollers/other/f/908/t/861109 today? This poster seems to be asking the same question as you and seems to follow this post here. However, he mentioned he is interfacing with the AD71772-2 and asked the question how to read 32-bit data via the SPI interface. Looking at the AD71772-2 datasheet (a device from Analog Device), it says to provide a 8-bit  SPI command to the device. This is the reason I answered as such. Now you wrote 'Now (example program which is running in the host) can send 8-bits data. But ADC does not answer. '. I wanted to make sure you are not referencing my answer in the other post in relation to the AD71772-2 device. You are stating you are using ADS12701. The two part numbers are somehow similar by name but made by two different companies. I apologize for asking the question if your post and the post from Pranav are entirely two different unrelated posts. 

  Please note that I cannot possibly read two different ADC datasheets (AD71772-2 and ADS12701) with hundreds of pages together and become an expert instantly. My knowledge is limited to the TM4C129 MCU only. I can tell you how the MCU SPI module works but cannot tell you all the different operating modes the external ADC devices are capable of. 

  3. With all that said, if the EK-TM4C1294XL is the MCU host and as a SPI master then the SPICLK should come from the host MCU. If you read the datasheet it shows the below excerpt. It seems like you need to give a command to start or stop a conversion and read data. However, in your first very post you wrote 'We are not using CS (chip select) and DIN (data input), Because TM4C1294 will not send any data to the ADC board. It will only read data.' How are you going to send a command to the ADC if your DIN is not used.

 

Hello Charles,

First of all Pranav Deep is not our college, I don't know this person and his company. I heard it from you for the first time. I am personally in charge of a company's research and development department. I have a team of 8 engineers and have been in the wheeled mobile robot business since 4 years. Unfortunately, our team has no experience with Texas Instruments MCUs.

I wouldn't want to confuse you. But our experiment today is not the same as our previous experiment.

Previous implementation:  Frame-sync mode interfacing      ( MCU is slave: it can only read , and data is 32bits)

Today's implementation : Freescale-SPI mode interfacing    (MCU is master: it can write and read data with 8 bits long packets)

We made this change as the way you suggested it.

If you remember, you sent us a scheme. This scheme shows the connections for the SPI interfacing mode. 

In SPI interfacing mode (Freescale SPI mode) TM4C12943 MCU is host (master) and it generates the serial clock (SCLK) signals.

The system works as follows as I understand: 

1- Host(=MCU=Master)  force the CS (Chip select) signal from High to Low state.

2- MCU send a start command (as a master) to the ADC (slave). Or  the conversion process in slave is already started state.

3- In every cycle, first  data sent by the host DOUT(For writing values or commands to the ADC's registers) accompanied with SCLK signals.

4- When cyclic conversion process  finished in Slave (ADC) it informs the MCU by DataReady (DRDY) signal cyclically. 

5- Host continue to send SCLK signals and takes the data from its DIN.

If the MCU(host) does not send SCLK signals, it cannot receive data.

I'm 54 years old man, but my memory is not so bad.

There is nothing that is inconsistent from my point of view. 

Best regards,

Mete

Why did we choose frame sync mode in the previous experiment:

In the user manual of ADC board, there is a warning : If you use an external MCU as a host, you must use a common system-clock in order to get better noise performance. (in order to prevent some harmonic distortion interference problems)

At that time we couldn't find a way to make an common clock for both boards ( host=MCU and slave= ADC). So we decided to apply frame-sync mode in which the common clock is not required.

Then we encountered a 32 bit data receiving problem in the TM4C1294NCPDT. Then we have contacted you.

Best Regards,

Mete

Hi Mete,

  I apologize and thank you for your clarification. The other post has too much resemblance to yours for several reasons. HE is asking about SPI. He is asking about reading 16 bits from a 32-bit SPI device. He is interfacing to a 24-bit Sigma Delta ADC. He stated he just read this post. Too much coincident leads me to think you are working on the same project. Anyway, it is my confusion, not yours. 

  Back to your waveform capture, where is the DIN? I'm referring to the DIN with respect to the ADC device. The DIN is used to write to the ADC and the DOUT is used to read from the ADC. I'm not sure if you are showing DOUT from the point of view of the MCU. You are sending the first command 0x53, 0x02 and 'i'. Without the DIN in the capture, it is really hard to know what is being written to the ADC device. Why are 0x53, 0x02 and 'i' being written to the ADC? Are they valid commands from the datasheet? 

  For the moment, let's suppose you are giving the correct commands as in 0x53, 0x02 and 'i'. I don't see anywhere in your code where you are waiting for the DRDY to go low to read the data. According to the datasheet, the data is ready after the DRDY goes low. You are writing three SPI characters immediately asynchronous to the DRDY. Don't you need to poll for the DRDY to go low before you attempt to read?

Please also understand it is a major US holiday and the response will be delayed. Thank you.

Hi Charles,

Thank you for answering, even though it's a holiday today.

In the oscilloscope screen-shot views, the designations are belonged to the ADC side. DIN and DOUT symbols are  the  Receiving input and transmitting output of ADC respectively.

Charles, we made a mistake. The DRDY signal from the ADC board is not connected anywhere on the MCU side. So we measured the DRDY signal from the ADC, but the other end of the cable is idle.

As you see in the Figure 103,   DRDY signal  must be connected to an Interrupt input of MCU. Still not connected.

After we realized this mistake, we didn't do anything.

1- We don't know which interrupt is to be used.

2- What will be the working principle of this interrupt?

3- Can we write the codes with our incomplete information?

The CS of ADC is connected to MCU's SSInFSS. But this connection is not necessary. Because we have only one slave for now.

Other connections are OK.

The example program sends three characters in ASCII code  S , P and  I .

 Riza ( responsible engineer from this part of project) has modified that characters. There must be instruction codes for ADC (instead of S, P, I)

This is the case. We're actually having trouble understanding some parts of the datasheet. 

In summary:

1-We need to set an interrupt in the MCU.

2-We need to connect the ADC's DRDY signal to that interrupt.

3-We need to change the example program accordingly or we must find an  appropriate example program.

 

I hope I'm not boring you. I believe you can help us to find a solution.

Thanks and regards

Mete

Hi Mete,

  

user5151893 said:

1-We need to set an interrupt in the MCU.

2-We need to connect the ADC's DRDY signal to that interrupt.

Yes, you want to use an interrupt. You can connect the DRDY to any MCU's GPIO inputs with interrupt triggered on the falling edge. There are TivaWare examples on how to setup the GPIO interrupt that you can reference. You can use the interrupt the synchronize your reading of the data,

user5151893 said:

3-We need to change the example program accordingly or we must find an  appropriate example program.

Yes, the three characters 's', 'p', 'i' are unlikely the right commands to the ADC. I don't know what are the command code. You will need to find out. Without the right command code, the ADC does not know what you are asking and does not return the correct data, I think that is what happened.

Thank you  Charles,

I will keep you informed of the steps during the progress.

Best Regards,

Mete