• State Resolved
  • Locked Locked
  • Replies 36 replies
  • Answers 4 answers
  • Subscribers 32 subscribers
  • Views 3614 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Multiple PWM generators counter registers are not the same value after asserting synch time base - is that normal behavior?

Genatco
Guru 55913 points

TM4C1294NCPDTi3:

Three configured PWM generators: Forcing PWM module reset in SYSCTRL and asserting PWMSynchTmeBase does not seem to zero all counter registers together. If the PWM generators all have the same clock source and are reset together, shouldn't generator counts (red box) all be the same value at any given time?

The strange part is the PWM generator CMPA/B matches are exact in up down counts and global synchronous updates occur together as expected. The problem would be the zero flag in each generator reacts to the count value.  Seemingly If SW attempts to use multiple GEN zero flags to drive service interrupts, those events could occur out of synchronization.

See:

  • 0
    TI__Guru**** 244400 points
    Hello Bp101,

    They never can be as the debugger reads them one register at a time. So when the next register is read there is a time lapse during which the counter value will have changed.
  • 0 in reply to Amit Ashara
    Guru 55913 points
    Hi Amit,

    Seems if that were entirely true the other registers values would not be exactly the same value. We can see the other register values change together in sync during the CCS debug refresh interval, why not the counters too?
  • 0 in reply to Genatco
    Guru 55913 points

    BTW: CB1 and Robert questioned several posts PWM individual generator center alignment not maintained but only between two generators does that occur. Otherwise the alignment is left or right depending on scope trigger polarity.

  • 0 in reply to Genatco
    TI__Guru**** 244400 points
    Hello BP101

    Which other registers are you referring to?
  • 0 in reply to Amit Ashara
    Guru 55913 points
    Hi Amit,

    The ones in the posted debug monitor such as CMPA/B and the global update flags. So if the counters reflect 80us period they don't have to count very high. Yet a bit higher than the CMPA/B matches, (roughly 40us at 50% duty cycle)and all the monitor registers are equal values accept the counters being 3 odd values and counting just as fast.
  • 0 in reply to Genatco
    TI__Guru**** 244400 points
    Hello BP101

    If the CompA/B values are being modified by the application then they could change as well and that would not have a co-relation either if they are being updated by the application as the debugger does not know about when the values are being updated.
  • 0 in reply to Amit Ashara
    Guru 55913 points
    Hi Amit,

    The point was the digital readouts CMPA/B are having even match counts to the application updates are (synchronous). Even though the counters are counting much faster than matches, seemingly should be within a few counts in the 1's and 10's position. The GEN counters values are spread hundreds of decimal positions apart (hex) and that begs question even at 100ms refresh rate in debug as to why so far apart in count value.

    Monitors in Eclipse debug are updated in linear progression, may take 100us IDE time and occurs every 100ms refresh rate of DAP reads. So I find it odd you would think the counters should be so far apart after a TimBaseSync. Perhaps it is delicate procedure when the TimeBaseSych is invoked and how?
  • 0 in reply to Genatco
    TI__Guru**** 244400 points

    Hello BP101

    BP101 said:
    Monitors in Eclipse debug are updated in linear progression, may take 100us IDE time and occurs every 100ms refresh rate of DAP reads

    You answered it. What would values look if they are so apart and being updated

  • 0 in reply to Amit Ashara
    Guru 55913 points
    Hi Amit,

    Actually it seems the issue is the PWM generators are not being enabled synchronously, rather one at a time. The monitor (writable/readable) only wiggle stepping into PWMTImeBaseSync. REG2 bits toggle so fast they never trip the yellow bar highlight no matter how many times step into directive.

    Delayed GEN enable bits seems to be how counts are so far apart even if we PWMTimeBaseSync prior. Some how need to HWREG all PWM generators enable bits synchronously not asynchronously as Tivaware does.

    Have any HWREG ideas that might kick start all counters clock enable bits synchronously???
  • 0 in reply to Genatco
    TI__Guru**** 244400 points
    Hello BP101

    JTAG is a slow serial interface. PWM is working at system clock. The JTAG can never read all registers in one shot, but over a period of time (A fact that I have stated over and over again in the post), so a change of values is as expected.
  • 0 in reply to Amit Ashara
    Guru 55913 points
    Hi Amit,

    >PWM is working at system clock.

    Not the PWM counter load value is only 0x7200 and total of 4800 ticks per second is well below USB transfer speed 250KBPS. This count register is not a free running, rather the preloaded count up/down takes 40us to reach the center and 40us to the bottom, 80us total 12Khz not even close to 60Mhz PWM clock speed.

    Makes no sense being the PWMTimeBaseSync resets all counters to zero prior to or even after enabling PWM clocks, makes no difference. This is high speed ICDI processor time and again the transfer of the CMPA/B values are always equal in the count. So it may be the PWM count registers are actually free running at PWM clock speed and not the actual period count?
  • 0 in reply to Genatco
    TI__Guru**** 244400 points
    Hello BP101

    Even though the USB is full speed, the bottleneck is still JTAG at 100KHz-1MHz which is a serial interface v/s application code running at system clock!!!
  • 0 in reply to Amit Ashara
    Guru 55913 points
    Hi Amit,

    So you are saying the MCU debug trace macro cell is slower than 1Mhz (1us)? The math 4800 ticks or 80us/4800=16.6ns/tick and of course do agree a few clock cycles would be missed in 1us JTAG scans. Yet the idea behind resetting all PWM generators to zero is that they all start counting from zero and the debug trace macro cell obviously sequentially reads all PWM count registers faster than 1us.

    Have noticed shifts in center alignment between generators, pwmB may not be in exact center of pwmA slightly shifted to the left. Even odder is the center occurs between any 2 generators, never any single generator produces center aligned signal in gen mode sync. Almost acts like the reset sync zero counters has no effect, if what I have described is not proper synchronous mode generator behavior. Odd thing is the center alignment shift between any two gens seems to works for motor commutation but has a few engineers scratching heads as to why this is occurring outside the datasheet explanation.
  • 0 in reply to Genatco
    TI__Guru**** 244400 points
    Hello BP101

    Please read the ARM Debug Architecture document and you will soon see that the 1us you have mentioned is way too optimistic and not to mention the processing delay of a PC!!!
  • 0 in reply to Amit Ashara
    Guru 47900 points

    Hello Amit,

    As poster craves correctness & exacting detail - is it not (far) more correct to note that one, "Calls function Sync Timebase" rather than "Asserting?"

    And - poster's claim of, "debug trace macro cell obviously sequentially reads all PWM count registers faster than 1us"  is NOT at all obvious to you/others - as well as this reporter...

    Poster's hopes/dreams lead SO often to incorrect tech. "REACHES" (guesses) - which he hopes to SELL- via inflated wordplay!    Only (that) is obvious...

  • 0 in reply to Genatco
    Guru 10570 points
    Engineers?

    You seem to be the only puzzled party.

    Robert
  • 0 in reply to Amit Ashara
    Guru 55913 points
    Hi Amit,

    Likely the TPIU is running at processor speed used for CCS debug, perhaps the ATB slave port access rate is to blame. Either way debug monitoring never catches or indicates changes in the PWMSYNC bits of REG2 even with a SW (goto) loop of repeated 1 second intervals to reset PWMSYNC.

    Oddly printF seems to report SYNC bits remain zero and never seems to Read a transition in PWMSYNC bits during a reset. Even SW clock speed (120Mhz) and reporting by the ETM can not properly determine if PWMSYNC bits are being reset.

    How can anyone be assured a reset is actually occurring when our tools can not properly capture the toggle bit event?

    PWMSYNC REG2: The bits auto-clear after the reset has occurred; reading them back as zero indicates that the synchronization has completed.
  • 0 in reply to Genatco
    TI__Guru**** 244400 points
    Hello BP101

    What you have been stating so far, has been validated and if any known issue has been seen, documented as errata. I don't believe that any of the functions you have mentioned in a logical flow of device code execution can be easily captured.
  • 0 in reply to Amit Ashara
    Guru 55913 points
    Hi Amit,

    Spent a few hours trying to capture a read back of REG2 indicating clearing the bits by HWREG asserts directly, but they must since REG2 is RWIC and always indicate zero. Perhaps since CMPA/B are all the same value we can assume the time bases all started at zero?

    Tried reverse SW calls , first reset REG2 then do a PWM peripheral reset call, assume is the same as SRPWM in SYSCTRL register? Some where in PWMSYCH note it states we must zero the counts after preforming a PWMSYNC. The question is then does a call to PWM peripheral reset access REG82? I can't easily know since Tivaware function << >> shifts values for registers all over the place.

    Register 82: Pulse Width Modulator Software Reset (SRPWM), offset 0x540
    The SRPWM register provides software the capability to reset the available PWM modules.
    A peripheral is reset by software using a simple two-step process:
    1. Software sets a bit (or bits) in the SRPWM register. While the SRPWM bit is 1, the peripheral
    is held in reset.
    2. Software completes the reset process by clearing the SRPWM bit.
    There may be latency from the clearing of the SRPWM bit to when the peripheral is ready for use.
    Software should check the corresponding PRPWM bit to verify that the PWM Module registers are
    ready to be accessed.
    Important: This register should be used to reset the PWM modules.
  • 0 in reply to Genatco
    TI__Guru**** 244400 points
    Hello BP101

    Yes. A PWM reset using SRPWM resets all registers of the PWM module. Also the steps mentioned are now mentioned in the post on Diagnostic Tips

    e2e.ti.com/.../374640
  • 0 in reply to Amit Ashara
    Guru 55913 points

    Hi Amit,

    >Yes. A PWM reset using SRPWM resets all registers of the PWM module.

    Ok but the silly question remains - does call below access SRPWM register? Tivaware call is very complex shifting operation, hard to decrypt the offset in ones head so easily. Must be a senior embedded programmer who wrote the complex peripheral reset routine.

    ROM_SysCtlPeripheralReset(SYSCTL_PERIPH_PWM0);

  • 0 in reply to Genatco
    TI__Guru**** 244400 points
    Hello BP101

    Yes, it does access the SRPWM register. The API you have mentioned is very simple (unlike some complex API calls)
  • 0 in reply to Amit Ashara
    Guru 55913 points
    Hi Amit,

    Thanks calculator agrees!
    There was errata PWM#2 RA1 if PWMCLK divisor is used. The TM4C1294NCPDTi3 is RA2 and that should no longer be an issue according to the last errata document, SPMZ850D–October 2013–Revised March 2015.

    So CMPA/B values would be inconsistent between generators, don't recall that occurring RA1 silicon even with a PWMCLK divisor.

    How did TI determine PWMSYNC was fixed in RA2 silicon?
  • 0 in reply to Genatco
    TI__Guru**** 244400 points
    Hello BP101

    Because it was tested after the RA2 silicon had arrived. The test procedures cannot be revealed as they are TI proprietary information.
  • 0 in reply to Genatco
    Guru 55913 points

    BTW: The reason to ask is oddly random Panics returned shortly after placing the PWMSYC bits before the clock divisor call and right after a PWM0 peripheral reset. Perhaps it matters were the PWMSYNC is placed in SW to avoid generator synchronization issues?

  • 0 in reply to Amit Ashara
    Guru 55913 points
    Hi Amit,

    Any thought as to why the linear placement PWMSYNC after PWMCLKDIV versus prior thus stops Mn0Faulting?

    My fault temporary moving PWMSYC above PWMCLKDIV for debug purpose. Did not see direct impact to low voltage system and left placement since last Friday.

    The one other thing different, PWMSYNC asserts after PWMnGENENABLE asserts directives. Is there some effect to generator edge timing or perhaps the PWMSYNC has no effect if placed above PWMCLKDIV? Would be nice to have such mention (debug link) if laboratory scientist witness a distinct counting difference.
  • 0 in reply to Genatco
    TI__Guru**** 244400 points

    Hello BP101

    BP101 said:
    Any thought as to why the linear placement PWMSYNC after PWMCLKDIV versus prior thus stops Mn0Faulting?

    I am not clear with what you just mentioned. Please elaborate.

  • 0 in reply to Amit Ashara
    Guru 55913 points
    Programs are linear progressive, TM4C executes read ahead buffering of instructions.

    Seems the order of instruction decode matters when HW synchronizes generators counts relative to the clock divisor position in the linear instruction decode cycle.

    If gen sync is executed before clock divide asserts a condition occurs that otherwise does not when the opposite order is executed.
  • 0 in reply to Genatco
    TI__Guru**** 244400 points
    Hello BP101

    I would ask you to check the errata for any known issue that is caused by the same.
  • 0 in reply to Amit Ashara
    Guru 55913 points
    Hi Amit,
    The point is the PWM#2 errata was corrected in RA2 so why should it matter if PWM0 gens sync prior to PWMCLKDIV configuration or after? Seems to me that answer will require laboratory investigation since debug engine can not indicate the PWMSYNC actually occurs though it seems to be magic in the air when it does.

    Perhaps the datasheet should indicate execution order of the PWMCLKDIV register is relative to PWMSYNC bits. Again the Mn0Faults are randomly tripped for unknown reason if the PWMSYNC is executed prior to configuring a PWMCLKDIV. I suspect PWM gen sync is somehow off by a few PWMCLKS when asserted at the higher clock rate 120Mhz versus 60Mhz of the clock divisor.
  • 0 in reply to Genatco
    Guru 47900 points

    Long ago - on this thread or (similar) other - this reporter suggested, "Sequence of function calls may impact outcome."

    And now - as KISS has (somewhat, and by accident) entered this (ongoing) fray - is it not time for your presentation of, "That code which causes the issue - as well as code variances - which cause still different behaviors?"

    Such clearly best enables this vendor - or nameless/faceless outsiders - to, "Consult for FREE!"   (always & only the goal - mais oui?)

  • 0 in reply to cb1
    Guru 55913 points
    If function call position generator enable was important for PWM_GEN_MODE_SYNC to have proper counter and clock synchronization, wouldn't PWMCTL register be able to enable all generator clocks synchronously? Surely the silicon wizards thought of that in this Cadillac Coupe Devil TM4C, or did the white wall tires hypnotize them?

    That is the only other relative puzzle piece Amit did not find of relative importance. Forensic science examines all the body parts for evidence leading up to the crime seen. The problem becomes tool related as our microscopes can only look so deep, the subatomic forensics is up to fellows in white vendor lab coats.
  • 0 in reply to Genatco
    Guru 47900 points

    And - you believe that said, "White lab-coat garbed" scientist will "comb thru" this bombardment - and seek to "experiment" in your behalf?   (and ONLY in your behalf - no one else displays ANY interest - is that not a fact?)

    Does not the proper presentation of the, "Shortest Code Block which evidences your (belief/reach/find)" earn the greatest chance of response from such esteemed, "Ivory Tower?"

    Or - you can sit idly - and "hope" that others will, "Rush to your aid."  

    As CEO of your firm - surely you know the importance of, "Comfort, Convenience" - in gaining the best efforts from others.   As NO/ZERO Sales Volume results from their assistance - should not you make (every) effort to, "Speed & Ease" White-Coated dive into BP waters?    Withholding the LONG Requested code block guarantees that ONLY (another) "Self-Awarded Verify" will grace your thread.    (White-coated personnel need not apply!)

  • 0 in reply to cb1
    Guru 55913 points
    I see no bombardment other than AKA making a mountain out of a simple mole hill!

    What's the point clocking issue was reported and claimed by vendor FE, symptom of random odd generator counts can not be debugged by end users of said product using CCS. Nor can proper generator clock synchronization be verified by SW calls, a double no win scenario!
  • 0 in reply to Genatco
    Guru 10570 points

    You might pause to wonder why you appear to be the only one reporting issues with PWMs.

    Also cb1 is correct (and it's something you should know considering your chosen field of endeavour). Being able to repeat an occurrence is essential to being able to find the cause. If you cannot (or cannot be bothered to) produce a method to reproduce the problem why should anyone make it a priority over issues they can reproduce or new developments customers need?

    Robert

  • 0 in reply to Robert Adsett72
    Guru 55913 points

    Robert's rant #2