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.

TM4C123GH6PM-External ADC SPI com. sometimes can not start A/D conversion

Hello 

I am currently working with 24-Bit external ADC. I have one continous problem since starting of my project.

Firstly I can correctly read A/D conversion data from external ADC. I calculated RMS value of it and also graph it. There is no problem. I also did time-stamp data and I am sure about I do not miss data between samples.

ADC conversion starts directly with my PWM output of my MCU. I do not control conversion. It is continous conversion. PWM is 4MHZ and SPI communication runs on 8 MHZ. 

The problem is sometimes when I reprogrammed my MCU, External ADC sends certain value is like "00000001 / 00000001 / 00000001". I checked MOSI request pin it seems like as always. I send address and R/W bit in one byte. I checked that frame I sent is correct.

Problem generally is solved when I power off device and on again. I couldnt understand where I am going wrong. 

My reading algorith is like 

void StartADC1()
{
	a = 0x0000;
	ADCdata = 0x00;
	clrbit(ADC_CS1,0); // Chip Select LOW( START Communication )
	while((SSI0_SR_R&SSI_SR_RNE)!=0)
	{
		a = SSI0_DR_R ;
        }


	a = SSI0_DR_R;								 // Dummy Read
	read_adress |= 0x41;
	SSI0_DR_R = read_adress ;
	while((SSI0_SR_R&SSI_SR_RNE)==0){};          // Receive FIFO Not Empty
	a = SSI0_DR_R ;

	ADCResult.VCH1_AN = (Read_ADC1(0)<<8) - VCH1_OFFSET;
	ADCResult.VCH2_AN = (Read_ADC1(1)<<8) - VCH2_OFFSET;
	ADCResult.VCH3_AN = (Read_ADC1(2)<<8) - VCH3_OFFSET;

	setbit(ADC_CS1,0); // Chip Select HIGH( Terminate Communication )
}

unsigned long Read_ADC1(char adress)
{
	a = 0x0000;
	ADCdata = 0x00;
	a = SSI0_DR_R ;					 // Dummy Read

	if(adress<3)
	{
		SSI0_DR_R = 0; 				 // Write SPIBufffer. Sets TX Flag, if not done read will not clock.
		while((SSI0_SR_R&SSI_SR_RNE)==0){};      // Receive FIFO Not Empty
		ADCdata += SSI0_DR_R;
		ADCdata = (ADCdata<<8);
		SSI0_DR_R = 0;
		while((SSI0_SR_R&SSI_SR_RNE)==0){};      // Receive FIFO Not Empty
		ADCdata += SSI0_DR_R;
		ADCdata = (ADCdata<<8);
		SSI0_DR_R = 0;
		while((SSI0_SR_R&SSI_SR_RNE)==0){};      // Receive FIFO Not Empty
		ADCdata += SSI0_DR_R;
	}
	return(ADCdata);
}

  • Serkan said:
    The problem is sometimes when I reprogrammed my MCU, External ADC sends certain value is like "00000001 / 00000001 / 00000001".

    Have you provided "necessary and sufficient data" so that those here may (properly) assist?   What is the definition of, "sometimes?"   That matters - does it not?

    As you report the issue (only) occurs when you, "Reprogram" - why do that?

    And you note the ADC, "sends certain values" - yet fail to describe these as good or bad - or note how far (if at all) "off-mark" they are.    Your helpers are thus left to "guess" - are they not?

    You'll do well to develop this (slight) bit of more critical thinking when composing your questions.   You've progressed quite nicely - yet any "vagueness" in your request will result in delayed - and too often "forced, multiple" responses - as helpers try to fill in (your) blanks.

    Now my, "Guess du jour" is that if a high number of SPI managed ADC transactions complete properly - you may be experiencing (some) "Out of Sync" issues.   These may be cured via, "Reset of both the MCU and ADC and/or Reprogramming of your MCU.   (the latter - just as you note)

    Any high speed serial connection is vulnerable - in many instances (regular) "resets" are scheduled - to insure data remains, "In Sync."

  • Hello cb1

    What do you mean in "necessary and sufficient data" ?

    Serkan
  • Read on - (my answering post) I'm at remote site - net is "in/out."
  • Hello cb1

    If you mean "necessary and sufficient data" as my readings yes as I mentioned in my post, I can get sufficient data from ADC. But sometimes this problem shows up.

    Serkan

  • I must ask again - what is the time period and/or frequency and/or number of (these) problems? (i.e. once in several hours, days, 20 minutes etc.)

    And - what is the direction and range of the "error." (i.e. ADC readings are, "too high", or "too low", or varied and they are "off-mark" by (10%, 33%, 75%))

    It is "necessary" that you supplied these findings. It is "insufficient" that you have not detailed them. At all!
  • Hello cb1

    Sorry for my English sometimes I cant get you well.

    If my conversion starts with no error, It continous 3 days long without any problem. This problem shows sometimes only when I  reprogram MCU and this shows up in the starting.

    Even once this error shows up, it never changes. But after power off and on device, it can solve and 3-4 day it does not show up

    Serkan

  • Thank you - if it is true that you are implementing, "continuous ADC conversions" - and proper results are achieved over a (continuous 3 to 4 day period) - my belief is that you've achieved, "beyond average."

    Usually my firm will not "trust" a serial link for such long, continuous periods (i.e. days), of operation. We may (regularly) replace "live data with special data" to confirm the transaction's correctness. And - in addition - we may perform regular, Peripheral Resets - both w/in the MCU and at the remote device. (that's an ADC - in your case.)

    You hold to the report of, "Reprogramming Issues." My firm uses J-Link probes & SWD - we "never/ever" have such issues. (low cost vendor boards may not prove the most robust - and we always advise that you employ (external) ~10K value, JTAG pull-up resistors. (never the higher resistance ones - internal to the MCU - unless you SEEK Programming issues!)

    You note that you, "sometimes can't get me" but do not provide a specific example - thus forcing me to, "Rewrite everything - or ask that you provide a quotation - so that I can "try again." As the forum provides NO Poster Guidelines - we cannot know your level of language - I try my best to write clearly - and to justify conclusions and/or arguments.
  • Hello cb1

    Thank you for your kindness..

    Firstly I am using XDS100V2 ARM JTAG emulator and I debug my program with it. I also have required pull-up resistors on my board.

    How should I reset my ADC ? In datasheet I had read that the best way to reset ADC is cut PWM clock in to ADC. It has RESET pin also but this RESET action is not recommended.

    Serkan
  • Serkan said:
    How should I reset my ADC? In datasheet I had read that the best way to reset ADC is cut PWM clock in to ADC. It has RESET pin also but this RESET action is not recommended.

    Note to forum readers (new) to poster Serkan's post: The ADC he references is an external, 3 channel, 24 bit ADC.

    Now I've not time now to download & read/review that ADC's write-up.   Yet - I find it extremely strange that the "halting" of the (external) ADC's clock (coming from your MCU) serves as "best way" to reset the ADC.   Further - the ADC has a Reset pin - but it's "Not recommended."   (does the tech writer for that ADC also advocate "walking thru midtown, NYC traffic - during rush-hour - w/headphones and fixated upon cell phone, too?)

    I'd ask that you reread - and then copy/paste here - the exact wording regarding the, "Not recommended use of the ADC's Reset!"

    Pardon but there's (still) more, unclear.   While you note that the ADC "suffers" (that's never been properly described - by the way) after your Reprogramming - do other portions of your program also (suffer - fail to run as expected, too?)   It would be (again) extremely unusual for just "one portion or segment" of your program to fail - while all others operate to perfection.   (or - my small firm has been extremely lucky to avoid that!)

    When we design for defense and/or medical - we most always devise a means to, "route to and switch in the voltage output from a known, stable, voltage reference."   Periodically we will "switch in" this known voltage - in this way we can note any ADC "difficulty" and even perform regular, "Auto-Calibration."   As you employ 24 bit ADC - such practice makes great sense for you, too.

    So you've got these assignments:

    • find for us and copy/paste the ADC's advice, "Not recommended use of Reset!"
    • what else fails - besides the ADC data transfer - after you, Reprogram?   Do all other parts of your program run correctly?   If so - how do you know?
    • Do you (always) Reprogram in exactly the same way?
    • Have you a 2nd board (or boards?)   We hate to spend great time on an issue which may be the result of a board/component imperfection.
    • Your thread's title is, "Cannot start ADC Conversion."   Yet you also wrote that you obtained 3 conversions - each w/the value of "1."  What (really) is your problem - it (still) has not been adequately explained.

    It's always vital that you "over supply current" and maintain the proper/specified voltage during such operation.   Measuring during anytime other than, "Peak Current Demand Times" may result in "False - Power OK readings!"   (thus my recommendation to use a "safe, over-current rated regulator - properly heat-sinked.)

  • Two questions

    Have you verified your distribution of sampling times?
    Why not power cycle as a matter of course when reprogramming?

    Robert

    Cb1's suggestion of periodically resetting to ensure synchronization if it cannot be ensured by toggling the chip select should be considered as well
  • Hello cb1

    1) Stoping MCLK for reset is used for reset all ADCs simultaneusly. Datasheet says this. Not recommended was my wrong remembering.

    2) Yes, I always reprogram my MCU in same way with  my JTAG emulator.

    3) Nothing fails except fixed data reading on SPI bus. I have working some communication lines,calculations, etc. They all work as expected. I get my DR interrupts in time. Everything is good except fixed data reading when problem occurs.

    4) I have only one factory made PCB. Everything is on this board. 

    Serkan

  • Thank you - is your (bad) "fixed data reading consistent?" (always nearly the same? and is it always near 0? (you reported all 3 channels as yielding "1" - many posts back.)
  • Hello cb1

    Yes it is always "fixed" pattern. It never changes. Today when I reprogram my MCU, I faced with this issue. I observed about a hour and it never changed.

    Serkan
  • And - may I ask - were you feeding in that exact same sine-wave signal? (as you previously described)

    What were the ADC readings? (near zero - as before or mid-scale or high in value?)

    When this happens - have you reset the MCU and remembered to cycle power?

    Have you verified that the ADC clock - sent by the MCU - actually reaches your ADC? And is the right level and waveshape? (square)
  • Hello cb1

    Yes. In my system nominal ADC peak value is around 600mV in differential reading channels. According to it I get certain scale by 1000mV in 24 bit(2^23 in decimal and 1 sign bit). But when this issue appears, I get always fixed value.

    It is solved when I power off and on my card. Actually I tried to only reset ADC. It does not affect. Only MCU reset effects it.

    Of course I verified ADC clock. Logic level,frequency, my sending "adress" frame all of them are surely correct.

    Serkan
  • OK - what is your "circuit treatment" of the external ADC's "Reset" line? Has it a pull-up resistor AND a small cap to ground - both placed very close to that Reset pin?

    You state that an "MCU Reset" effects the ADC. Are you saying that upon an MCU Reset - the ADC (always) performs? If that's the case - indeed we have a solution...
  • Hello cb1

    I have only series 100R resistor between MCU GPIO pin and ADC_Reset pin. I send RESET from my MCU

    cb1 actually as I said I only tried to reset ADC. It did not solve problem. But when power on and off my board. It means "reset my MCU and ADC too" solves problem.

    Serkan
  • Pardon my friend - but your treatment of the ADC's (critical) Reset pin does not appear, "normal/customary." Have you reviewed that ADC's data sheet - especially the wordage AND any schematic - revealing any/all connections to that ADC's Reset pin?

    To my mind - this is the first we've learned of your connection to the ADC's Reset pin - and I'd much prefer to see the (more normal) connection I outlined earlier - which may be extended to include your GPIO connection thru 100R. I would NOT rely on that "Reset Connection" as you have now - though!

    With this latest ADC Reset revelation (discovery) the odds have shifted dramatically to an "imperfect ADC Reset" as your (major - perhaps only) issue. May I suggest following the ADC vendor's data sheet described treatment of that Reset pin. If that's not covered (but I'm almost sure that it is) you may install a "10K pull-up R joined to a 0.1µF C" their common connection tied to ADC Reset - the pull-up to 3V3 and the other side of the cap to ADC ground. Both components must be CLOSE to that Reset pin! (1" or less distance)

    Believe you're very close now - do follow these suggestions & I'll bet you'll succeed...
  • Hello cb1

    I configured my ADC_RESET pin with 10K pull up and 100nF cap but it did not solve too.

    I spent my whole day with it. I am about to crazy. Only power off and on reset helps this annoying problem. Resetting ADC not solving, Resetting MCU sometimes work but " sometimes". Power off and on "always" solve problem. I cant get really problem in this way.

    Serkan

  • I feel your pain. (of course that helps) I'll download the ADC data sheet - I've yet to do that.

    Dawns now that the connection to your GPIO (may) have impacted the R-C network we deployed upon your ADC Reset pin. There's a quick way to test - open the connection to your 100R - so that there's no connection between that reset and your MCU.

    Should that improve things - you must change your GPIO "output" from "push-pull" to "open drain." This will be less impacting upon the ADC.

    Years ago we used certain of that vendor's "accessory" ICs - never their MCUs. I mention this as I will try to "borrow" a similar ADC board - and see what results we obtain.

    There is a major point which demands your clarification, "You note that Power OFF and ON "always" solves." Does this mean that (only) Power ON (from OFF) "causes" the problem - or at minimum gives rise to it - often.

    What may be "in play" here is "Power Up Sensitivity" of (either) the MCU or ADC or both. (my bet is the ADC - as such issue would have been well noted here. {far more MCUs are sold than that ADC}) I'll note the current draw of the ADC - we may be able to power cycle (just) the ADC - and cure the problem in that manner.
  • Hello cb1

    Thank you. I mean when problem occurs after reloading program my MCU, resetting MCU rarely solves problem. But after I power off and on my board, I see that my ADC data are correct as expected.

    Serkan
  • OK - some of your craziness has transferred to me - I could not find your ADC's mention - and then recalled that (mention) occurred w/in your earlier, similar post.   And now I've found.   And quite a data sheet it is - 88 pages!

    Please realize - this ADC is a highly complex device - we must communicate carefully - with great detail - if we are to succeed.

    On (just) page 1 I note the following - which raises concern:

    Programmable Data Rate up to 125 ksps:

    - 4 MHz Maximum Sampling Frequency

    - 16 MHz Maximum Master Clock

    - High-Speed 20 MHz SPI Interface with Mode 0,0 and 1,1 Compatibility

    We are presented with four different frequencies here - and we're still on page 1!   Note especially these 3:

    • 4 MHz Sampling Freq
    • 16 MHz Master Clock
    • 20 MHz SPI Clock

    It would appear that the SPI Clock may exceed the Master Clock - that seems unusual.

    I've just spent a good hour reading/reviewing your ADC's (MCP3919) datasheet. (88 pgs!)   This is a highly complex device - I find 32 registers - this ADC is extremely powerful - thus demands great attention to detail.   We must begin somewhere - let's (hope) that you've mastered the register management - and dive into the HW.   (and this is far from a TM4C-centric issue (now).)

    Data Ready (DR) (page 21) this is an output from the A-D to your MCU.   From the manual: "After each conversion is finished - a logic low pulse is furnished."   You must employ this signaling pulse to interrupt your MCU - and then transact w/the A-D.  I agree w/the manual's guidance to "pull up" w/100K to VDD.  Chip Select is also covered here, drive the pin low (after) you've released the A-D from Reset.

    SCK, SDO, SDI, Reset (page 22) All of the SPI signals are standard - provided you've properly matched the SPI frame format.  (0,0 or 1,1).   The A-D Reset pin is the most critical one here - manual advises this must be driven low for 100nS, minimum.   I note "no" cap nor pull-up on Reset (schematic, pg 57, Fig 8-1)

    Are your connections between MCU and ADC as short & direct as possible.   And are they (all) really secure, well soldered?   (a bad joint or connection would really distress!  Please don't allow that.)

    Iirc yours is an official eval board - so my concern must be w/the interconnects you've created.   Controlling the ADC's Reset via your MCU is critical.

    ADC Resets - both HW & SW - are well detailed on pg 28.  The fact that there are two - of different types - warrants your investigation - does it not?

    I'm willing to devote (bit) more time but you've (or someone) has set a high hurdle and more firepower may be required...

  • I've downloaded & read the ADC's data as well as the "formal eval board data" - for your MCP3919 device.   Earlier I asked if yours was a "home made" or "pro/factory board."   You indicated it was a, "pro."   Below are scans from the pro board's manual - is this (identical) "two board combination" exactly what you have - and have been using?   (this is very important...)

    In addition - here's the hook-up info:

    Now if this Figure 2-1 agrees with what you have - won't you experience "contention" between your TM4C MCU and the ADC vendor's MCU?  All here could be, "chasing their respective tails" if this proves the case.   If you do not believe that the ADC vendor's MCU directly connects to your ADC (as the above drawing reveals) kindly describe "HOW you've come to that conclusion."  (for example - how have you insured that (only) your TM4C MCU connects to the SPI, DR & Reset pins on the ADC?   Note that that fact has (never) been explained in your writings - and potentially may render all work done in your behalf - of little value...

    So complex a device - and so complex an issue (sporadic failure on power-up) - demands high & proper detail...

  • Hello cb1

    I know these schematics. I have worked so hard before designing my board. I researched all ADC reference designs, design tips for MCP ADC series, development board schematics etc. I am not using development board. I have ADCs integrated on my own board. 

    Serkan

  • Ouch - your own board is scary. Even our (own) board is scary. (i.e. "any" first time board - at/around this level of complexity - is extremely suspect.)

    Board I've shown is 129 (USD) and should be, "bullet-proof." Firm/I always "recoil" at test/verify of user's new, "one and one only pcb!" Such boards (always) present, "Maximum Randomness" - any and everything is suspect.

    From the several hours I've spent in reviewing the ADC's 88 page manual (it is quite a nice part - BTW) it's Reset pin "toggle" should cause it to behave "exactly" as a POR. You must insure that your SPI signals, & DR, are proper (inactive) during your (ordered, non POR) Reset of the ADC.

    Then - and only then (after the ADC has emerged from Reset - should you start your MCU to ADC transaction flow.

    As we're at some distance - w/out seeing clear scope captures of Reset, each SPI line and DR - the identification & correction of your "intermittent POR issue" is unlikely to be solved quickly nor efficiently.

    If it were me - I'd invest in that vendor's Eval Board - which is "known good." Much as you (and ALL of my firm's clients) "believe" and "WANT" their self-designed board to be, "perfect" - that proves (rarely) the case - and my firm invests hours to find & fix.

    Scope caps - just as listed - really are required.   And your acquisition of the factory Eval board eliminates board execution as an issue.   Your "saving" of the "pro" board's cost flows down to your helpers here - does it not?   (i.e. "You" save at the time/effort expense of the helpers...)