TM4C129ENCPDT: GPTM Timer in PWM Mode: Behavior is different at first period.

twelve12pm said:

Is there anything I could do to the timer that will avoid this first time phenomenon?

Cannot 'avoid' - but suspect that this can, 'Minimize the duration' of that offending transition.     (and sometimes - such proves, 'Good for Gov't Work.')

Simply start your code process w/'far smaller values' entered into (both) 'TimerPrescaleSet() & TimerLoadSet().'    The offender is likely to (still) appear - yet is greatly reduced in duration - which should lessen (possibly eliminate) the unwanted 'triggering of other hardware.'    (may require 'glitch filters' - applied to those hapless/downstream, potential 'glitch recipients.') 

Crack staff wonders if,  'This issue occurs when the Timer alone - minus the Prescaler' - is employed.

A 2nd 'work-around' would involve, 'Disabling the triggering' of those downstream devices until after (that known, illegal trigger signal) has executed & passed.    (even if the offender is 'periodic' - so long as the duration of the offender is known/predictable - this method should succeed.    albeit at the cost of HW & SW.)     Work-Around 2A would see your 'Gating the direct Timer Output' - such that it is 'constrained to your exact needs.'

As in all such cases - it proves 'always wise' to test for this occurrence upon 'other boards' and especially upon other MCU Timers - to confirm that a 'rare anomaly' is not 'unduly exercising' your 'loyal, captive, 'light-seeking' (cell is w/out windows) diagnostic crüe'...

Hi Twelve12pm,

  Can you try 

MAP_TimerControlLevel(TIMER5_BASE, TIMER_A, true) and place it before you call MAP_TimerConfigure?

cb1_mobile said:

Crack staff wonders if,  'This issue occurs when the Timer alone - minus the Prescaler' - is employed.

Ah, it's not actually used as a prescaler. When the GPTM half-timer, normally a 16-bit timer, is used in PWM mode, it becomes a 24-bit timer. The Prescaler and Prescaler Match registers are used as the upper 8 bits of the 24-bit value.

cb1_mobile said:

As in all such cases - it proves 'always wise' to test for this occurrence upon 'other boards' and especially upon other MCU Timers - to confirm that a 'rare anomaly' is not 'unduly exercising' your 'loyal, captive, 'light-seeking' (cell is w/out windows) diagnostic crüe'...

cb1_mobile said:

As in all such cases - it proves 'always wise' to test for this occurrence upon 'other boards'

Charles Tsai said:

Hi Twelve12pm,

  Can you try 

MAP_TimerControlLevel(TIMER5_BASE, TIMER_A, true) and place it before you call MAP_TimerConfigure?

Just to clarify, do you mean to add this call before the code shown above, without introducing any other changes to that code? 

HI,

  I meant to say that you remove your current line with 

MAP_TimerControlLevel(TIMER5_BASE, TIMER_A, false) and replaced with the MAP_TimerControlLevel(TIMER5_BASE, TIMER_A, true) and place it before you call MAP_TimerConfigure

Charles Tsai said:

Something like this:

// Output pulse on T5CCP0, PB2, using Timer5A

// Configure output level as normal (not inverted)
MAP_TimerControlLevel(TIMER5_BASE, TIMER_A, true);

// Configure half timer as PWM (0x0400000A)
MAP_TimerConfigure(TIMER5_BASE, TIMER_A, TIMER_CFG_A_PWM | TIMER_CFG_SPLIT_PAIR);

// Configure waveform to pause when CPU halts in debugger
MAP_TimerControlStall(TIMER5_BASE, TIMER_A, true);

// Configure to trigger interrupt on rising edge
MAP_TimerControlEvent(TIMER5_BASE, TIMER_A, TIMER_EVENT_POS_EDGE);

// Set PWM period: Put high byte in prescaler register, low word in interval load register
MAP_TimerPrescaleSet(TIMER5_BASE, TIMER_A, (100000 >> 16) & 0xff);
MAP_TimerLoadSet(TIMER5_BASE, TIMER_A, 100000 & 0xffff);

// Set PWM duty: Put high byte in prescale match register, low word in match register
MAP_TimerPrescaleMatchSet(TIMER5_BASE, TIMER_A, (100 >> 16) & 0xff);
MAP_TimerMatchSet(TIMER5_BASE, TIMER_A, 100 & 0xffff);

I did that.

It appeared promising at first but unfortunately it makes the situation worse.

What I did was:

Invert the output signal as you suggested.

Compensate for it by inverting the duty cycle.

Reverse the interrupt edge trigger.

Now, the low output pulse at the beginning is eliminated, just as I hoped, but:

The problem now is that if code disables the timer with MAP_TimerDisable(), the signal goes low, instead of staying high. This also means that when we re-enable the timer, we will get the unwanted extra triggering.

Excitement followed by disappointment :-(

cb1_mobile said:

twelve12pm

You are correct that there are no windows in this cell, er, I mean, lab.

We are told that 'Alexandre Dumas'  (*)  past resided w/in your (always)  'dark/dank cell' ...  {now claimed 'converted' to lab space.}     Yet - you ARE (or should be) "Twelve NOON" (clearly a 'light & truth  seeker') thus your 'escape from dungeon' (lab/cell & so questionably/concerning named  'other'  MCU) - argues for a FAR 'More general & especially accommodating 'Re-Usable' solution!'

Even if  vendor's Charles (so carefully orchestrated)  'Special Timer Sequencing' code creation should work - it strays WAY FAR from KISS!    And simply 'manipulates' the (otherwise effective/intuitive) MCU Timer API into a,  'Strange &  Forced Compliance!'    (Unsuccessfully too it appears (so far) -  as you've just noted!)     Can that (ever) be good?

Are not 'universal solutions' most always - the best solutions?    (you KNOW that answer)    Staff's earlier/inspired suggestion of (externally) 'Gating/Controlling' the, Natural Timer's, 'Predictable Response' - via your 'management of external logic' (which may be used repeatedly - under many conditions) surely trumps a 'One-Off, manipulative 'deep dive' into unique,  'MCU Orchestration!'   (that 3rd trumpet (stage left)  also known as (aka) 'other' - does sound 'Off.')   

As it is 'one time use only' - and may 'exit the stage'  - when updated TWare (promised today - early 2020) arrives to 'trumpet fanfare' - such 'painfully crafted/sequenced' API functions - most always - send shivers - and if (really) required - should be properly detailed (via detailed Register Handling - especially such Sequencing Instruction) w/in the MCU manual.    (and NOT 'just here' - a single post - soon/shortly rotated away ... into 'forum oblivion.')

Not all 'MCU Behavior' (from any vendor) will 'mesh to perfection' w/all of our unique,  'design desires/signal goals.'     We can then attempt to:

• 'trick/manipulate the MCU into some form of compliance'   (maybe)
• or (more productively) develop 'REUSABLE, External Gating/Control Methods' under MCU control (adored by the VC/investor community)

which may be used w/many (even NAMED) MCUs - as these external/accommodating designs prove endlessly 'flexible, precise & (did we say) - Re-Usable!'

Endless 'massaging/bandaging' of a (nameless/other) MCU - unless the volume is 'consumer-like' (highly unlikely here) - appears w/out great merit...

(*)  past occupant -  (same) prison cell/now (ahem) 'lab!'  -  "carcéraux de Monte Cristo"     

(Likely the (near) derivation of,  'incarceration') ... Tech/History 'mix' - often required to break thru/lessen 'tech-drone' - while restoring interest & focus...

I gave this quite a bit of thought over the last day or so and I have come to the conclusion that:

Your assessment is 100% CORRECT.

Given that this particular signal causes such a big problem if it doesn't comply with our wishes 100% of the time, I think it was folly to design the board this way.

Also, given that the VC/investor community reportedly loves external gating so much, I think we shouldn't let them down.

I now think that in the next iteration of this board, there should be external gating, and I think it needs to be a combination of a gate and a flip-flop (or some such design) to eliminate race conditions between changes to gating and a pulse that may be in progress at the time of gate input changes.

Unfortunately, the board on my desk in the cold (because the boss sets the thermostat at sub-absolute-zero temperatures) dark (because we need to save electricity so the beloved incandescent glow above my head has been replaced by LED lights which I swear give off BLUE light (no one believes me but it is actually a scientific fact documented in the datasheets thereof)) -- this is like a Nathaniel Hawthorne sentence that by the time you reach the end you forgot what the beginning was, but thankfully that author repeats the beginning to remind us -- the board that sits on my desk right now is so darn expensive that I'm going to make the thing work, whatever it takes. NO BOARD LEFT BEHIND!

I'll try Charles Tsai's suggestion when I'm in the lab tomorrow and let you know if that solves the problem.

cb1_mobile said:

... when updated TWare (promised today - early 2020) arrives to 'trumpet fanfare' ...

Crack staff (having 'showed up' (today, Sunday) @ 05:00 wonders aloud,  'Where IS da damn (official) GREEN?'    (Not that your totally unique, 'la creation verte' escapes Great Applause!)     Staff senses that your 'inept LEDs overhead' have rendered your lab (nearly) 'BRAILLE REQUIRING'  - thus you could not see the 'This RESOLVED button!'     (Hit it quick - as it too is headed the way of  ***LIKE*** and (even) normal/customary MCU naming convention!)

You are correct in the recognition that your 'almost white' Leds  start as (most always) 'native' Blue Leds:

• augmented/manipulated by a (barely) capable (Krazy-Glued) 'color filter!'     
• or by the addition of special 'fluorescing material' (developed by Nichia) ... these WORK!

Low cost (consumer lighting) Leds Torture that pristine BLUE into (so pleasant) 'almost white'    (Appears that (both) you & 'Source Two' - have past read of my firm's (back room) stockup of (almost) every incandescent bulb in/around Chicago - just prior to their 'ill conceived' BAN!)    BTW - we fully power these in winter - 'heating our space' (as well as 'perfectly' white illuminating) - which proves beneficial to you - too! 

Surely one as clever, detailed & spirited as you EASILY recognizes the 'HUGE PARALLEL' between 'FRANKEN-LED'   and    'FRANKEN-API.'   Does (either) really work?     (Blue IS White - keep repeating that!)      And 'if' it succeeds (for now) - will 'New/Improved API releases' (around the corner - on (some) 'to do' list) - for sure - accommodate this (none too adhesive) 'API bandaid' downstream.     (after you've 'forgotten' such 'undocumented API' massaging!)    

Is it not time that the 'Frankenstein Monster' be, 'Returned to deep sleep?'      And to recognize that, 'Blue is NOT White' - even though - especially though - consumer packaging proclaims it so...

Hi Twelve12pm,

  Glad that your problem is solved. I hope the solution I provided is robust enough in all situations you will run into. I guess that will be your task to confirm. cb1's suggestions with external gating is worth exploring. 

twelve12pm said:

Is there an update to TivaWare coming soon?

(If so, I have several improvements to offer for inclusion in it.)

Can you please open a new thread and list the improvements you want to see or bugs that you want addressed. We will evaluate and accommodate the requests accordingly.

Thanks for reporting back.    While the board appears now 'possible to work'  (your words) - your test protocol has been (necessarily) brief - and the chance for unanticipated consequences cannot have been positively ruled out.    Timers have many options and may coordinate with (and be accessed by) several other MCU Peripheral Modules.   Note too that (only) an extremely small 'sub-set' of operational conditions are likely to have been exercised - thus it should be asked if this 'fix' has earned sufficient 'support' - to be promoted into the (pending) Active API Update.      It is expected that a firm of T.I.'s size/stature - would, 'Not be so quick to Rush the Embrace of (even) this resourceful (potential) 'fix.'   Recall that even a 'seemingly' slight change - may produce a cascade of side-effects - few of these 'immediately evident.'   

To fully/properly 'anticipate, manage & identify' all possible behaviors and/or ramifications - especially    in such short a time-frame - proves extremely unlikely.    Risk/Reward would not smile on such a (barely) proven implementation...    Resourcefulness cannot trump robustness - no matter the 'short-term' appeal...    At least one here remains firmly ... in opposition to such practice!

cb1_mobile said:

Crack staff (having 'showed up' (today, Sunday) @ 05:00 wonders aloud,  'Where IS da damn (official) GREEN?'    (Not that your totally unique, 'la creation verte' escapes Great Applause!)     Staff senses that your 'inept LEDs overhead' have rendered your lab (nearly) 'BRAILLE REQUIRING'  - thus you could not see the 'This RESOLVED button!'     (Hit it quick - as it too is headed the way of  ***LIKE*** and (even) normal/customary MCU naming convention!)

Ah, yes, the much vaunted green splash. Just think of all the barrels and barrels of green ink in which you might have submerged yourself (with the requisite safety equipment, of course) during all those long and lonely months you were absent from our Hero Vendor's LIKE-less forum. I think I'll take a page out of Howard Hughes' book and acquire said vendor just to reinstate the LIKE button. (As soon as I earn my first trillion.)

Charles Tsai said:

Hi Twelve12pm,

  Glad that your problem is solved. I hope the solution I provided is robust enough in all situations you will run into. I guess that will be your task to confirm. cb1's suggestions with external gating is worth exploring. 

twelve12pm

Is there an update to TivaWare coming soon?

(If so, I have several improvements to offer for inclusion in it.)

Can you please open a new thread and list the improvements you want to see or bugs that you want addressed. We will evaluate and accommodate the requests accordingly.

Yes. I will do that right away.

Charles Tsai said:

Hi Twelve12pm,

  Glad that your problem is solved. I hope the solution I provided is robust enough in all situations you will run into. I guess that will be your task to confirm. cb1's suggestions with external gating is worth exploring. 

twelve12pm

Is there an update to TivaWare coming soon?

(If so, I have several improvements to offer for inclusion in it.)

Can you please open a new thread and list the improvements you want to see or bugs that you want addressed. We will evaluate and accommodate the requests accordingly.

Link: e2e.ti.com/.../837698

twelve12pm said:

I think I'll take a page out of Howard Hughes' book

Why just, "a page?"      After subduing the 'Wayward (other) Timer' - shouldn't you be sufficiently energized to, 'acquire one equally (well-tested) monster aircraft?'    (at least - a 'properly scaled model')     Should it be noted that Mr. Hughes' creation (built from Birch - Not Spruce) made a 'single test flight' - just over 1 mile - 60-70 feet above the water - and lasting barely a minute!     'Deja Vu - all over again' - some would proclaim!    (credit 'NY Yankee catcher Yogi Berra' for that 're-animated (i.e. well Timed) phrase!'  

Somehow that past/exhaustive 'test protocol' rings (strangely familiar) ... Museum documents (later) revealed that the giant Craft's 'Timer' glitched during its First Period - yet that (extremely) short flight (some called it 'inconsequential')  was ruled a success.   

Part of Mr. Hughes' 'genius' was his 'total subscription' to, 'Risk-Reward' - and his giant craft (most properly) - 'Never Flew Again!'

cb1_mobile said:

twelve12pm

I think I'll take a page out of Howard Hughes' book

Why just, "a page?"      After subduing the 'Wayward (other) Timer' - shouldn't you be sufficiently energized to, 'acquire one equally (well-tested) monster aircraft?'    (at least - a 'properly scaled model')     Should it be noted that Mr. Hughes' creation (built from Birch - Not Spruce) made a 'single test flight' - just over 1 mile - 60-70 feet above the water - and lasting barely a minute!     'Deja Vu - all over again' - some would proclaim!    (credit 'NY Yankee catcher Yogi Berra' for that 're-animated (i.e. well Timed) phrase!'  

Somehow that past/exhaustive 'test protocol' rings (strangely familiar) ... Museum documents (later) revealed that the giant Craft's 'Timer' glitched during its First Period - yet that (extremely) short flight (some called it 'inconsequential')  was ruled a success.   

Part of Mr. Hughes' 'genius' was his 'total subscription' to, 'Risk-Reward' - and his giant craft (most properly) - 'Never Flew Again!'

Hughes' problem was that he didn't have me programming his firmware.

twelve12pm said:

Hughes' problem was that he didn't have me programming his firmware.

Or have 'Charles' to 'Bash' the 'Goose's API' into some form of (essentially untestable) compliance...

Toyota's engineering staff devoted over 10K HOURS in 'Test & Evaluation' of that, 'Unintended Acceleration'     And (perhaps like 'some' here) - came up dry!

It fell to a 'highly organized/persistent/systematic' KISS deploying 'Expert Witness' - to discover those 'exact conditions' - under which the cars would (unwantedly) Accelerate - despite the 'Absence of Command!'   

Toyota's lawyers, engineers, the jury & the entire courtroom 'gasped' - when the expert witness 'DEMONSTRATED LIVE & FORCEFULLY' - JUST HOW' the deadly 'Unanticipated Acceleration' was 'guaranteed to occur!'     And unfortunately - multiple deaths occurred - as the 'Tech discovery' - indeed required the great investment of: 'Time, Funds, Focus & SMARTS' - to identify...

There IS a lesson there - for those who will 'take heed.'

Believe me, I listen. Nothing ships without passing a tremendous amount of testing, neither hardware nor software. The next board iteration will include something in hardware to control this signal. The one on my desk will be made to work FOR INTERNAL USE ONLY! This board already has correction wires on it and will NOT be shipped to a customer. We might glue a SMD with its feet up and more correction wires (all of them in your favorite color: GREEN) to test the external gating of the clocking signal. I intend to have all the bugs worked out before we spin a new board!! Hopefully our stalwart schematic and PCB guys won't introduce any new surprises!!

By the way, instead of putting gating in front of this PWM signal, it occurred to me that there are clock ICs, some of them programmable, which might provide this signal more reliably. Something to look into...