• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 31 subscribers
  • Views 1027 views
  • Users 0 members are here
Support feedback
Options
Options

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.

TM4C1294NCPDT: Baffled why ANIx sample amplitude decreases

Genatco
Guru 55513 points
Part Number: TM4C1294NCPDT
Other Parts Discussed in Thread: INA240, REF2033, LM94022

ADC0 is configured 2MSPS (32Mhz) with 2x hardware averaging, ANIx channel TSHN 0x4 encoding, Rs=1.3Megohms (impedance) according to Tina, virtually no load.

Now the INA240 output we added 3Rk series and also isolated & filtered ANIx pin via 100R/200pf to ground. As the PWM duty cycle speeds up so does the INA240 output increase at ANIx input. Yet the scope widget output and digital decimal display of signal value do not follow all increases, often fall behind or roll near the same value depending on PWM duty cycle speed. 

The sample amplitude measured from a steady state PWM duty cycle at one point matches well with external test equipment and diverges as the duty cycle increases up to a certain point. Yet at a much higher duty cycle the sample amplitude returns to an almost matching value in the scope widget peaks being sampled but the digital decimal value is a bit behind. Hence voids occur in the data even as the sample sequencer INT priority is lower than PWM generator that caused the sample start. 

Even when the sequencer is being triggered via GPTM blanking one shot timer thus delaying start of sample PWM output created, the FIFO misses the boat entirely at times.

Why does the SAR ADC not keep up with high speed PWM duty cycle changes with PWMCLK (60Mhz), sampling at certain test points in the ANIx signal? It seems the PWM clock and the ADC0 clocks are meandering or phase shifting no matter how precise the sample timing or software filtering is made to handle INA240 samples. The same is true for LM94022 temperature sensors producing nearly the same behavior when ever the PWMENABLE register is enabled. The synchronized timing seems to get so wacked out it often disconnects USB0 device client in exact same behavior. The 25Hhz XTAL for MOSC has a large digital ground plane on the bottom of PCB directly under it. The concept aimed to isolate digital ground from analog by 1 ferrite bead drop, 50mohm resistance to bucking switchers analog ground. In that way the digital ground is a much cleaner signal also noted by the use of ADC internal VREFA+ (2v2 LDO) where a REF2033 was far to noisy.

  • 0
    Guru 117855 points

    How MANY Topics  - can we emplace - w/in ONE posting?      That is (or at least should be) the 'real' Subject here - is that not so?

    Let's see:  (in chronological order)

    • INA240
    • PWM Duty Cycle 'speeds up' (unlikely - the Duty Cycle rises - does it not?)
    • Scope Widget Output & Digital Decimal Display
    • Voids (past disproven) still invade the posting
    • Sample Sequencer & PWM generator's Interrupt priority
    • Sequencer triggered by  'GPTM blanking, one-shot timer'
    • Delayed start of of sample PWM output
    • SAR ADC fails to keep up w/high speed PWM duty cycle changes - when sampling at 'certain test points'
    • PWM and ADC0 clocks 'seem' to meander - or phase shift
    • LM94022 temperature sensor
    • Synchronized timing reported to (often) Disconnect USB0 device
    • 25MHz (not 25Hhz) xtal has a large digital ground plane - bottom side - directly beneath

    That's TWELVE Tech Items - where do you suggest hallowed vendor agents (holiday working)  - even begin?

    YOU KNOW your system - and your (many) changes & customizations.    (even 'reaches')      Vendor has, 'NO Such Knowledge'  (they are unlikely to 'Live & Breathe' - the on-going BP Saga!)      Thus - just might - your expectation be (somewhat) too high?

    It is suspected that your (long directed) USE of 'KISS' - One MEASURABLE, TIGHTLY FOCUSED, TEST SUBJECT (in your case - Question) AT A TIME - WOULD SURELY IMPROVE VENDOR'S UNDERSTANDING - AND RESPONSE...     TWELVE TECH ITEMS - SO INTERWOVEN (and just briefly detailed) - drives (even) strong men to tears ... cannot (possibly) yield the best, soundly reasoned, response!

    (edit)  11:45 CST ...  It is noted that you've 'snuck-in' ... even MORE!     To those "Magnificent TWELVE" - we (now) must ADD:

    • ferrite bead drop - 50mΩ (to bucking switcher's Ana Gnd
    • REF2033 - reported 'far too' (not to) noisy

    Vendor agents (race) ... assuredly - to, "Step right up!"     (those unfortunate enough - to have NOT already - escaped to 'them thar' Hills...)      Might the report of (some) Green Tinge - complete your report?

  • 0 in reply to cb1_mobile
    Guru 55513 points
    They created the peripheral octopus not us so the ADC sample timing is on their block not ours. Note they all have ties to the ADC sample clock relative to PWM clocking source being SYSCLK DIV/2.

    Point is vendors to determine how such a phase shift might occur between clocks thus effecting ALL sensors/DC signals being sampled! Did vendor not expect the PWM peripheral in controlling an DC inverter would generate internal bus noise or has it ever been tested by them. Even with the EK-XL launch pad the ADC samples would often produce voids in the very same data.
  • 0 in reply to Genatco
    Guru 117855 points

    What to say - vendor's 'boilerplate' places ALL application success - rather clearly - upon your door-step.      (you may note 'my' long past - boilerplate extension, 'Providers of Content'  realized thru Blake's kind intervention - at my urging...to offer (some) protection to we 'outside' contributors...)

    You - and you alone - stand responsible!      The "point" - as you bandy about - is  NOT what you note...

    Providing (some) Crystal Clear FOCUS - Tightly Spec'ed (SINGLE ISSUE) is your best means of gaining (any) serious response.      (and you KNOW that...)

    Unanswered - to your (now)  'FOURTEEN POINT MANIFESTO'  just   WHERE WOULD YOU LIKE  THE VENDOR TO START?

  • 0 in reply to Genatco
    Guru 55513 points
    All our ducks are in a row, seemingly the same can not be said for this class of MCU maintaining phase between clocks when PWM bus noise arrives internally! We even long past had to abort using GPIO's for PWM generators B output to trigger ADC sequencers as it randomly locked the MCU on EK/XL launch pad.

    One thought is the PLL phase lock is being effected by low level PWM pulses bleeding into the AHB from ANIx inputs. That seemingly would answer why so many samples derived via mixed clocking noise fail to lock/hold any period and miss the sample window entirely.
  • 0 in reply to Genatco
    Guru 117855 points

    Do call me - when today's 'Manifesto" reaches TWENTY Points!       And AGAIN - just WHERE do you suggest that the VENDOR BEGIN - to Assist/Rescue YOU?

    If - as you claim - 'ALL of your ducks are 'in a row'' - I 'fear to view' - a 'row-less' MASS of Ducks!     (heard just today - loudly quacking - from your grass-free lawn (burial ground for destroyed semi-devices.)

    Does one (really) Solve Problems - by adding endlessly - to the number of 'guessed' (potential) impacting events?

    Is not (much) of your code/design - built upon such 'unique' (oft unconfirmed) 'beliefs' - drifting closer & closer to ... (House of Cards?)

  • 0
    TI__Guru 72500 points
    Hi BP101,
    I doubt that the A to D or PWM clocks are shifting. Could it be that when interrupt routines align you are unable to service the A to D FIFO in time and are dropping samples?
  • 0 in reply to Bob Crosby
    Guru 55513 points

    Hi Bob,

    Happy 4th to you!

    Originally my thought too since 1 second intervals invoking Trigger Processor start to fall apart. Yet PWM pulse width is a huge widow 80us pulse width periods, sample interrupt handlers kept short and current has dedicated 3 step FIFO1. That FIFO1 is being triggered start sample 1.25us after via GPTM one shot from PWMENABLE 80us periods. Also varied GPTM from 500ns up to 2us and TSHN encoding 0x0-0x8 made no direct difference to capture missing pulses.

    When I say pulse voids in amplitude; single pulses that make up peaks in phase current simply disappear from the base line samples, conversions finished 2.5us after each 80us period begins. So a 3 amp base line may have 0.6A-0.8A peak pules in each 80us period of scope widget/digital count disappear as PWM duty cycle increases/decreases in speed. Widgets update @100Mbps inside Ethernet GUI, show ADC samples of current captured inside PWM duty cycles.

    The PWM duty cycle seems to effect TSHN hold time on ANix signals even as INA240 output has 1nf cap near output and 200pf on the ANIx pin. Hardware averaging 2x (ADC0/1-FIFO1) improved basic capture amplitudes. In the same time frame LM94022 sensors may rapidly jump +/- 1 degrees (ADC1-FIFO1) trigger processor 1 second intervals. It seems PWM noise is effecting SYSCLK as two GPTM used for taco/PWM controlled/monitored fan speeds being derived from 200hz edge counts start to drift up/down so reported fan speed is all over the place. Things start to fall apart except the PWM module & one GPTM, FOC commutation timer remain stable via ANIx monitored EMF (ADC0-FIFO0) signals. EMF is very low amplitude under 2v, TVS/ferrites near signal source, RC decoupling 0.5" from MCU pins. It don't seem like EMF is the cause for TSHN hold on samples and other GPTM values to start drifting.

  • 0 in reply to Genatco
    Guru 55513 points
    Story gets even better when +24v supply switcher also powers DC inverter the low side recently replaced LM94022 reports correctly. When +80v linear powers DC inverter, also has isolated regulated +24v powering +5v buck down into +3v3 LDO (on PCB) both grounds common into PCB bottom ground plane and causes the LM94022 to report negative digital temperature values.

    The replaced LM94022 measured 2.9k to ground pin and new one 8Megohm same as high side LM94022. Negative temperature digital values are result of higher voltage on the ANIx input pin. It seems ANI-16 (pin 18) has odd current flow yet measures in high megohms range, 0.672v diode drop to ground. Nearly same values as ANI-9 (pin 123) used for high side LM94022, Oddly ANI-8 pin 124 next to it is a noisy pin but does not effect the temperature sampling.
  • 0 in reply to Genatco
    Guru 55513 points

    It would seem current is flowing out of ANI-16 input from ADC switching more so when MCU/inverter are powered from two isolated potentials! That is a +24vdc linear regulator bucked down +5v then +3v3 via LDO has an isolated transformer winding separate from the +80vdc unregulated transformer winding powering the inverter. There is also a small amount of potential difference on ANI-16 even as a switching +24v supply powers the MCU and the DC inverter.

    ANI-16 current seems to flow out pin 16 raising LM94022 sensors reading during PWM0 commutation. Both LM94022 are powered from the same dedicated 3v3 LDO regulator. The MCU dedicated +3v3 LDO regulator is also powered by the same +5v buck down regulator driven by +24vdc. That eventually lead to the low side LM94022 output being compromised when the inverter was producing unusually high voltage peaks early on. 

    Seemingly that caused 2R9k short to ground inside the low side LM94022 which compensated for unusual current flow out ANI-16 most noticeable for PWM commutation and split supply potentials. We had to compensate the formula for low side LM94022 as it reported a bit higher samples than the high side sensor (ANI-8) even with same +24vdc supply powered the MCU and inverter. ANI-16 current flow was always present with several different MCU replacements being made on the same PCB for various other issues.  

    The samples produce lower temperature values on low side LM94022 when the inverter is commutating otherwise ANI-16 always reads an odd sample potential! Seemingly similar issue is plaguing AIN-1, ANI-2, ANI-5 for current samples from INA240 outputs, even after MMZ1608B ferrites were recently placed on the outputs.