• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 31 subscribers
  • Views 1039 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.

TM4C1294KCPDT: PWM0 GEN0 fails to configure control register & ADC0 trigger & load interrupt fails.

Genatco
Guru 55973 points
Part Number: TM4C1294KCPDT
Other Parts Discussed in Thread: EK-TM4C1294XL

Two spanking New MCU's each indicate DIDO being RA2 silicon, are free of RA1 silicon errata PWM#03. 

Yet GEN1, GEN2, GEN3 control registers configure without any issues and work as expected.

This same configuration issue (PWM0-GEN0) was past posted years ago this forum relative (EK-TM4C1294XL) launch pad, MCU TM4C1294NCPDTi3, RA2 silicon.

Oddly the ADC triggers/interrupt registers are configured (GEN0) however the counter is not configured so ADC0 trigger and count zero interrupts never execute.

Why would PWM#03 even be an issue so many years after it was resolved by RA2 silicon?

  • 0
    TI__Guru**** 191906 points
    Hi BP101,
    Which event are you using to trigger the ADC? is it the counter being equal to zero as the event for generating the ADC trigger? I'm not clear when you said "however the counter is not configured". The PWM module is duplicated four times in the device. If it works for others GEN1-GEN3 then I will expect it to work for GEN0 as well.
  • 0 in reply to Charles Tsai
    Guru 55973 points

    Charles Tsai said:
    If it works for others GEN1-GEN3 then I will expect it to work for GEN0 as well

    Me too but the GEN0 control register is not configuring yet GEN1-3 do. Oddly GEN0 (control register) was showing all bits properly configured but (not enabled) when the MCU was faulting from another bug I was tracking down.

    UART3 is not configured in Utility folder (uartstdio.c) and past making the very same UART3 calls under RTOS was not faulting the MCU. Could not understand why an imprecise bus error kept faulting since UART3 was showing configured in debug. Anyway that is when I noticed GEN0 control register was being configured after an immediate MCU exception fault 0x3.

    So it seems something perhaps SW is not allowing GEN0 control register to properly configure.

  • 0 in reply to Genatco
    Guru 55973 points
    >> Which event are you using to trigger the ADC? is it the counter being equal to zero as the event for generating the ADC trigger?

    No bits in GEN0 control register are being set so the gens counter will not count even though the triggers and interrupts are set.
  • 0 in reply to Genatco
    TI__Guru**** 191906 points
    Hi BP101,
    I misunderstood the problem you were reporting. At first I thought you were saying that with GEN0 properly configured, it will NOT generate trigger to the ADC. Reading your reply again, you are saying the opposite where the triggers and interrupts are set when the GEN0 registers are not set. Correct me if my understanding is still wrong as I don't have the prior history of this problem.
  • 0 in reply to Charles Tsai
    Guru 55973 points
    You are correct GEN0 control bits are all 0x0 but single step the GEN0 Tivaware initialization, all bits get set properly. What seems to be occurring is UART3 printf() strings being processed after that somehow over write GEN0 control register and clears all the bits. Hard to know for sure since debug jumps quickly to Resume after the printf() string is output.

    Same text strings sent via UART0 cause no issues since GEN0 can NOT be used on the EK-TM4c1294XL.
  • 0 in reply to Genatco
    TI__Guru**** 191906 points
    Hi BP101,
    Can you use the watchpoint to watch for any writes to the GEN0 registers when running the UART3 printf statement? Have you played with the stack size and see if it makes any differences?
  • 0 in reply to Charles Tsai
    Guru 55973 points

    That UART3 was a rouse, seems the PC jumped single stepping (F6) past the actual code lines causing the issue shown below. Oddly the only thing that changed was GEN0 was GEN1 on the launch pad so this might be an undocumented errata.  It don't matter if any (single) line is commented (//) the control register bits all remain 0x0. All 3 lines have to be commented out to stop GEN0 from being overwritten 0x0. I notice the last three values Fault0-2 are all 0x0

        ROM_PWMGenFaultConfigure(PWM0_BASE, PWM_INT_GEN_0, 0, PWM_FAULT0_SENSE_HIGH);
    ROM_PWMGenFaultConfigure(PWM0_BASE, PWM_INT_GEN_1, 0, PWM_FAULT1_SENSE_HIGH);
    ROM_PWMGenFaultConfigure(PWM0_BASE, PWM_INT_GEN_2, 0, PWM_FAULT2_SENSE_HIGH);

  • 0 in reply to Genatco
    Guru 55973 points
    BTW commenting them is not an option so answer why does that occur and get the green flag of resolve.
  • 0 in reply to Genatco
    Guru 117855 points

    Let's compare/contrast your (failing) code vs. our (long past) working code.

    Your code,   "ROM_PWMGenFaultConfigure(PWM0_BASE, PWM_INT_GEN_0, 0, PWM_FAULT0_SENSE_HIGH);"     // Note your Parameter 2 - "NOT meeting Spec!"

    And our (old, working) code:

    ROM_PWMGenFaultConfigure(PWM0_BASE, PWM_GEN_0, 900, PWM_FAULT0_SENSE_HIGH);   // 2500 18 Aug  '14
    ROM_PWMGenFaultConfigure(PWM0_BASE, PWM_GEN_2, 900, PWM_FAULT0_SENSE_HIGH);
    ROM_PWMGenFaultConfigure(PWM0_BASE, PWM_GEN_3, 900, PWM_FAULT0_SENSE_HIGH);

    Knowing there appears (some) tendency to dispute - arrives now the "Defining Legal Authority" - that from the "PDL User Guide" - always REQUIRED Reading!

    21.2.2.13 PWMGenFaultConfigure

    Configures the minimum fault period and fault pin senses for a given PWM generator.
    Prototype:
    void
    PWMGenFaultConfigure(uint32_t ui32Base,
    uint32_t ui32Gen,
    uint32_t ui32MinFaultPeriod,
    uint32_t ui32FaultSenses)
    Parameters:
    ui32Base is the base address of the PWM module.
    ui32Gen is the PWM generator for which fault configuration is being set.   Must be one of PWM_GEN_0, PWM_GEN_1, PWM_GEN_2, or PWM_GEN_3.      

    Such is NOT your parameter:  "PWM_INT_GEN_0"  is it?
    ui32MinFaultPeriod is the minimum fault active period expressed in PWM clock cycles.
    ui32FaultSenses indicates which sense of each FAULT input should be considered the “asserted”
    state. Valid values are logical OR combinations of PWM_FAULTn_SENSE_HIGH
    and PWM_FAULTn_SENSE_LOW.

    My splash of,  "Pre-St. Paddy's" Green IS (quite properly) AWAITED!

    Note that we employ, "PWM_GEN_MODE_FAULT_MINPER"  and obtain,  ALL PWM Outputs "Going Quiet" - even with - and especially with - "Just a SINGLE Fault pin being triggered!"

  • 0 in reply to cb1_mobile
    Guru 55973 points

    Had discovered as much that omitting INT somehow made way into call could resolve the issue.

    Might it also have been an easy award for FE to achieve after spotting the obvious mistake?

    Hunting ghosts busters this forum seeking to spread green goo onto very same issue two years ago CB1 argued against such an issue could ever occur.

  • 0 in reply to Genatco
    Guru 55973 points
    The reason INT worked ok with EK-TM4C1294XL is that GEN0 could not be used and the default M0Fault is (0x0) high level. So the call with INT was not doing anything unless GEN0 was configured.
  • 0 in reply to Genatco
    Guru 117855 points

    As usual - your final sentence - yields, "Huh?"      (this referenced 2 "BP posts" back.)     Note that hallowed vendor supports, "Age over Beauty" (when posts arrive simultaneously) - thus the "tie" here - goes to BP...

    All GREEN welcomed! (even when in "goo" format)     As "Paddy's Day" nears - Green Fix must be achieved from (Non-Shamrock) sources.     Mercî.

    Do you care to link to the writing claimed to "argue against" (the unspecified) issue?     Firm/this reporter - have long exploited the power of a, "Single PWM Fault Input" (NO NEED for THREE) to Positively SILENCE - ALL SIX - PWM Outputs (yet enable, "Next PWM Cycle RECOVERY") during a "transient" Over-Current (or other) Fault Condition...

    We must note - in defense of the "FE" - that his method would have (surely) yielded success.      This reporter made simple (very simple) observation - which proved correct.     (yet provided NO support "clues.")