LM4F232H5QD Eval Board: Configure to use external power

Hi David,

     I think, you can supply power to the USG OTG Cable. Then, set the POWER SELECT jumper to USB OTG. See, the LM4F232 Evaluation Board User's Manual for reference.

-kel

We have 3 such boards. (one is very early BGA ver.)  Not near now - thus cannot comment upon Kel's direction.

However - seek to "sound the alert" that your power distribution scheme should very much insure that the Eval Board "never" is the recipient of signal/voltage input when the Eval Board itself is not powered.  Prototyping/experimentation is "prime-time" for "less than fully considered" power lash-ups - dead Eval MCU - too often the unwelcome result.

This may be avoided by employing an appropriate, single power supply - to power all interconnected boards/components.  If multiple voltages exceed the capability of a single power supply - you must devise a means of "safely gating" power - insuring that MCU is always up/running - prior to (or coincident with) the energizing of any interconnected board/component.

Further - you must insure that any signal/voltage fed to the MCU (and/or other Eval board components) is w/in the ratings specification of both MCU and/or effected component(s).

And - while convenient - USB connector may not be adequately robust for use as "power inlet" for a mobile device.  Should that USB connection break/fail - other "hot" signals/levels from more robustly, power connected devices may "wreak havoc" upon your Eval Board...  You may wish to consider...

Hi Kel,

Thanks for the suggestion. Here is what I tried

(1){ moved the power select jumper to the OTG pins, plugged a wall wart USB power supply (it recharges a buddy's Kindle) into the OTG connector with this result:

the power LED comes on,  the OLED display comes on, the screen half filled with noise, and that's it, no other activity.

When I revert and plug the ICDI cable back in the same thing happens:

the power LED comes on,  the OLED display comes on, the screen half filled with noise, and there's no communication via virtual COM port.

Then, clicking the 'debug' button in the CCS IDE: the code runs to main(), clicking the 'resume' button the program lands in the 'fault'  routine. By a combination of pressing the board's reset button, clicking on the the IDE 'restart' button and the IDE 'core reset' button and re-downloading the program via the 'debug' button the program in the board eventually works properly again (whew!).}

(2){ disconnected all cables, removed the ICDI jumper, attached +5volts to the +VBUS screw terminal. Results were exactly the same as (1) above.}

I lack understanding of the 'reset' and power circuitry and am hoping someone has a quick and dirty solution.

Thanks,

Dave

Hello cb1,

In light of your cautionary message I feel lucky to have not already destroyed the thing! I have now taken your info into account. I'm new to ARM and the vast array of configuration options involved but a good answer to the key question will allow me to put the prototype on the ground moving freely.

The program runs properly while debugging so...

What to do to make it run properly without the ICDI cable?

Hibernation ability is not needed (at this time).

Is there some point-to-point on-the-board soldering I could do to overcome the sophistication responsible for the problem?

Thanks,

Dave

"Surgeon/Stellaris User - do no harm" - in play here, too.  Have too often arrived @ clients - found DOA MCUs, multiple other ICs - caused by "rush to and imperfectly planned inter-connect."  Thus - my caution.

I'm mobile today - our 3 boards far - but we did "hardwire 5V" into the 232 Eval during long past, initial eval...  You must insure that your external 5V properly feeds to the eval board's 3V3 regulator input - I cannot recall the best board location we found to introduce that 5V.  (hope to be able to review/report upon touch-down, later tonight)

If at all possible - suggest that you avoid any board to board interconnects - or any signal inputs other than those provided "naturally" by the Eval board - at this your early stage development.  You should be able to "fake" any helpful input signal via "seeding" that input variable - no external connection (danger) required...

We don't use nor like CCS - far prefer IAR (work w/multiple ARMs - many vendors) - thus we attached/controlled via 10 pin "mini" JTAG/SWD (we use SWD exclusively) -  never encountered ICDI issue.   Seems to be a rash of such "Run to Main" issues impacting CCS - perhaps forum search may expand...

Thanks cb1,

I look forward to your note. In the mean time I'll study the schematic and the PDFs for the auxiliary chips.

(FYI: I soldered wire-wrap machine pins into the holes along both sides of the board and stuffed it into a pair of breadboards.

The connections to external components consist, so far, of only:

    3 PWM outputs to corresponding inputs on LMD18200 H-bridges and one generic servo motor

    2 GPIO outputs to the 'direction control' inputs on the H-bridges

    4 QEI inputs from the two drive motors

    3 ADC inputs: two from a mini-joystick and one from an infrared range finder)

Soon I'll attach a radio transceiver and send joystick commands from a remote etc.

Cheers,

Dave

Spirit always willing - flesh not so much - late landing last night...  Did find/review QFP ver. of your 232 Eval board (have one rare BGA ver. too) and find a nice size PTH labeled 5V - topside.  (near rt side header, about 1/2 way down)  That 5V access point was untouched/intact - thus we must have made our tests/data grab via one of the 2 USB connectors.  Noted that the top one (icdi) had nice "hold-down/securing" pads - we find these far more robust than smt connectors lacking that "hold down" feature.

Disappointed to find no 5V inclusion on either of the 2 header strips.  So - what you may consider is the "slice/interruption" of one unneeded signal (or a 3V3 output) from among the header array - and the addition of a short, secure jumper wire to the 5V access point.  This will enable 5V input power to your board - w/out using either of the USB connectors. Again - our experience argues against mini USB connectors in a mobile and/or vibration-rich environment...

Suspect that you'll proceed faster/easier by temporarily replacing your sensors w/simple pots - wired to swing between 0V and 3V3.  Build your experience & confidence w/ MCU's ADC prior to sensor hook-up.  (assumes one or more sensors are analog based - many have moved toward serial)  By "stealing" 3V3 from the Eval's header strip - you eliminate the chance of external voltage impinging upon an unpowered MCU.  Be careful not to exceed the Eval board's 3V3 regulator's output capability.

(broken record follows:)  Do consider using a single power supply to power each/every device which may interconnect to your Eval board.  This may prevent the input of signals/levels - prior to the MCU's being powered.  So many discount this eventuality - yet it is rampant!  SAFE trumps sorrow...

You've added RF to your mix - you may find suggestions rendered on sister forum of some use:

http://e2e.ti.com/support/microcontrollers/stellaris_arm/f/471/t/276349.aspx

Buried by work today - likely will "go quiet" till way late or beyond...  Bon chance...

david genge said:

Once 'ROM_IntMasterDisable();' was placed just after main(){ system worked perfectly.

Really - just after main() - "Danger Will Robinson!"

Suggest that you scan each/every file w/in 232 Eval group - doubt you'd find such "just after main" implementation!

Instead - might some HW or improper SW condition be causing an interrupt to "fire" - and the improper service of that interrupt quite naturally causing your fault?

Classically - faults as you describe (timer/PWM initialization) result from failure to Enable said peripheral - prior to addressing/use.  Prevent via early use of, "ROM_SysCtlPeripheralEnable()."

Self awarded, "Verify Answers" (not being subject to peer review/approval) may lead others to unsafe outcomes...

Hi cb1,

Yes it was quite a mystery but after playing with it for a while found that preventing premature interrupts solved intermittent fault entry. Here's relevant code chunk. If you notice any errors like 'order of execution' or 'redundant operations' etc. I'll appreciate your comments. And, quite right about 'Verify Answers' faux pas, new to forums in general, didn't mean to cut your aid off at the knees. I used the 'timers' project as the starting point for development.

//***************************************************************************** LM4F232H5QD
// GRD robot 1
//*****************************************************************************
int main(void){

    // Enable lazy stacking for interrupt handlers.  This allows floating-point
    // instructions to be used within interrupt handlers, but at the expense of extra stack usage.
    ROM_FPULazyStackingEnable();

    // Set the clocking to run directly from the crystal.
    ROM_SysCtlClockSet(SYSCTL_SYSDIV_1 | SYSCTL_USE_OSC | SYSCTL_OSC_MAIN | SYSCTL_XTAL_16MHZ);

    // prevent interrupts from firing before initialization complete
    ROM_IntMasterDisable();

// *************************************************************************************************** LM4F232H5QD
// Initialize UART 0
// ***************************************************************************************************

    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);
    ROM_GPIOPinConfigure(GPIO_PA0_U0RX);
    ROM_GPIOPinConfigure(GPIO_PA1_U0TX);
    ROM_GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);
    ROM_UARTClockSourceSet(UART0_BASE,UART_CLOCK_SYSTEM);
    ROM_UARTConfigSetExpClk(UART0_BASE, ROM_SysCtlClockGet(), 115200,(UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE | UART_CONFIG_PAR_NONE));
    ROM_UARTEnable(UART0_BASE);

    ROM_SysCtlDelay(16000000/10); //delay a little
    sprintf(stringbuffer, "\n\n\n\r\tGarden Robot Design \n\n\r\tUART \n\r");    send(stringbuffer);

// *************************************************************************************************** LM4F232H5QD
// Initialize Timer 0 - background tasks
// ***************************************************************************************************

    // Enable the Timer module
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER0);

    // Configure the 32-bit periodic timer.
    ROM_TimerConfigure(TIMER0_BASE, TIMER_CFG_PERIODIC);

    // Set timers duration
    ROM_TimerLoadSet(TIMER0_BASE, TIMER_A, ROM_SysCtlClockGet() / 64);

    // Setup the interrupt for the timer timeouts.
    ROM_IntEnable(INT_TIMER0A);
    ROM_TimerIntEnable(TIMER0_BASE, TIMER_TIMA_TIMEOUT);

    // Enable the timers.
    ROM_TimerEnable(TIMER0_BASE, TIMER_A);

    ROM_SysCtlDelay(16000000/10); //delay a little
    sprintf(stringbuffer, " \tTimer 0\n\r");    send(stringbuffer);

// *************************************************************************************************** LM4F232H5QD
// Initialize Timer 1 - servo motor sweep control
// ***************************************************************************************************

    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER1);
    ROM_TimerConfigure(TIMER1_BASE, TIMER_CFG_PERIODIC);
    ROM_TimerLoadSet(TIMER1_BASE, TIMER_A, ROM_SysCtlClockGet() / 128);
    ROM_IntEnable(INT_TIMER1A);
    ROM_TimerIntEnable(TIMER1_BASE, TIMER_TIMA_TIMEOUT);
    ROM_TimerEnable(TIMER1_BASE, TIMER_A);

    ROM_SysCtlDelay(16000000/10); //delay a little
    sprintf(stringbuffer, " \tTimer 1\n\r");    send(stringbuffer);

// *************************************************************************************************** Lx4F232H5QD
//    Quadrature Encoder Interface
//    Initialize right side QEI  for use by the right side drive
//    Uses GPIO Port D bits PD6 & PD7 (no Index output on the encoder)
//    Note: Port D pin 7 defaults to a NMI input at reset. That functionality is protected by a mechanism
//    which must be "unlocked" before it can be made available to another module (like QEI1).
// ***************************************************************************************************

    // Enable Port D, G & C modules for configuration
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);    // right motor QEI encoder: PD6 - PHA, PD7 - PHB
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOG);    // left  motor QEI encoder: PG3 - PHA
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOC);     // left  motor QEI encoder: PC6 - PHB

    // Make pin direction of bits 6 and 7 INPUTS (this may be unnecessary?)
    ROM_GPIODirModeSet(GPIO_PORTD_BASE, GPIO_PIN_7 | GPIO_PIN_6, GPIO_DIR_MODE_IN); // right motor QEI encoder: PD6, PD7
    ROM_GPIODirModeSet(GPIO_PORTG_BASE, GPIO_PIN_3, GPIO_DIR_MODE_IN);                // left  motor QEI encoder: PG3
    ROM_GPIODirModeSet(GPIO_PORTC_BASE, GPIO_PIN_6, GPIO_DIR_MODE_IN);                // left  motor QEI encoder: PC6

    // Apply gentle pull ups to all of the encoder input signals
    ROM_GPIOPadConfigSet(GPIO_PORTD_BASE, GPIO_PIN_7 | GPIO_PIN_6, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD_WPU);
    ROM_GPIOPadConfigSet(GPIO_PORTG_BASE, GPIO_PIN_3, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD_WPU);
    ROM_GPIOPadConfigSet(GPIO_PORTC_BASE, GPIO_PIN_6, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD_WPU);

    // Switch Port D bit 7 from default NMI input to QEI
    GPIO_PORTD_LOCK_R   = 0x4C4F434B;    // Write 'key' into Port D's Lock register: enables access to Port D's Commit register
    GPIO_PORTD_CR_R    |= 0x80;            // Set bit 7 ON to ALLOW Port D bit 7 to be switched from NMI use to QEI use
    GPIO_PORTD_AFSEL_R |= 0x80;            // Selects alternative usage for the pin
    GPIO_PORTD_PCTL_R  |= 0x60000000;    // Selects QEI0 PHB0 in particular (page 722 & 1405 in LM4F232H5QD manual)
    GPIO_PORTD_CR_R    &= !0x08;        // Clear bit 7  to Re-lock

    // Tell the GPIO modules which pins will be QEI type pins
    ROM_GPIOPinTypeQEI(GPIO_PORTD_BASE, GPIO_PIN_7 | GPIO_PIN_6);
    ROM_GPIOPinTypeQEI(GPIO_PORTG_BASE, GPIO_PIN_3 );
    ROM_GPIOPinTypeQEI(GPIO_PORTC_BASE, GPIO_PIN_6 );

    // Enable programming access to QEI Modules 0 & 1
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_QEI0);
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_QEI1);

    // Set mux to connect QEI module inputs to port pins
    ROM_GPIOPinConfigure(GPIO_PD6_PHA0);
    ROM_GPIOPinConfigure(GPIO_PD7_PHB0);    // now redundant ?
    ROM_GPIOPinConfigure(GPIO_PG3_PHA1);
    ROM_GPIOPinConfigure(GPIO_PC6_PHB1);

   // Configure the QEI    modules (encoder:500lines * 2 channels * 2 edges * 5.9gearatio = 11,800 counts per revolution)
    ROM_QEIConfigure(QEI0_BASE, (QEI_CONFIG_CAPTURE_A_B | QEI_CONFIG_NO_RESET | QEI_CONFIG_QUADRATURE | QEI_CONFIG_NO_SWAP), HOME_POSITION);
    ROM_QEIConfigure(QEI1_BASE, (QEI_CONFIG_CAPTURE_A_B | QEI_CONFIG_NO_RESET | QEI_CONFIG_QUADRATURE | QEI_CONFIG_NO_SWAP), HOME_POSITION);

    // Configure QEI velocity production
    ROM_QEIVelocityConfigure(QEI0_BASE, QEI_VELDIV_1, 26000);
    ROM_QEIVelocityConfigure(QEI1_BASE, QEI_VELDIV_1, 26000);

    // Enable QEI velocity production
    ROM_QEIVelocityEnable(QEI0_BASE);ROM_QEIVelocityEnable(QEI1_BASE);

    // Enable QEI modules
    ROM_QEIEnable(QEI0_BASE); ROM_QEIEnable(QEI1_BASE);

    // Zero the position counters
    ROM_QEIPositionSet(QEI0_BASE, 0); ROM_QEIPositionSet(QEI1_BASE, 0);

    ROM_SysCtlDelay(16000000/10); //delay a little
    sprintf(stringbuffer, " \tQuadrature\n\r");    send(stringbuffer);

// *************************************************************************************************** LM4F232H5QD
// Initialize PWM for drive & servo motors. Drive motors on GPIO Port H bits 0 and 1 & Servo motor on bit 2
// ***************************************************************************************************

    // Enable GPIO port to be used for pwm
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOH);
    // Enable PWM Module 0
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_PWM0);

    // Set pin direction of bits 0, 1 and 2 of port H to outputs
    ROM_GPIODirModeSet(GPIO_PORTH_BASE, (PWM_OUT_0_BIT | PWM_OUT_1_BIT | PWM_OUT_2_BIT), GPIO_DIR_MODE_OUT);

    // Set pin pads to standard TTL type using 2milliamp drive current
    ROM_GPIOPadConfigSet(GPIO_PORTH_BASE, (PWM_OUT_0_BIT | PWM_OUT_1_BIT | PWM_OUT_2_BIT), GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD);

    // Configure GPIO Port H module pins 0 & 1 & 2 for use by a PWM module
    ROM_GPIOPinTypePWM(GPIO_PORTH_BASE, (PWM_OUT_0_BIT | PWM_OUT_1_BIT | PWM_OUT_2_BIT) );

    // Set mux to connect PWM modules to the Port H pins
    ROM_GPIOPinConfigure(GPIO_PH0_M0PWM0);    // left motor
    ROM_GPIOPinConfigure(GPIO_PH1_M0PWM1);    // right motor
    ROM_GPIOPinConfigure(GPIO_PH2_M0PWM2);    // servo motor

    // Tell PWM module to count down without synchronizing to any other devices and to continue to run during debug
    ROM_PWMGenConfigure(PWM0_BASE, PWM_GEN_0, PWM_GEN_MODE_DOWN | PWM_GEN_MODE_NO_SYNC | PWM_GEN_MODE_DBG_RUN);
    ROM_PWMGenConfigure(PWM0_BASE, PWM_GEN_1, PWM_GEN_MODE_DOWN | PWM_GEN_MODE_NO_SYNC | PWM_GEN_MODE_DBG_RUN);

    // Divide the system clock to achieve the desired frequency for servo
    ROM_SysCtlPWMClockSet(SYSCTL_PWMDIV_8);

    // Set motor drive periods.
    ROM_PWMGenPeriodSet(PWM0_BASE, PWM_GEN_0, PWM_Period );    // 1khz for drive motors

    // Invert the outputs so subsequent calculations deal with pulse widths
    ROM_PWMOutputInvert(PWM0_BASE, PWM_OUT_0_BIT | PWM_OUT_1_BIT, true);

    // Set initial pulse width
    ROM_PWMPulseWidthSet (PWM0_BASE, PWM_OUT_0, 2 );    // right motors
    ROM_PWMPulseWidthSet (PWM0_BASE, PWM_OUT_1, 2 );    // left motors

    // Start the timers in generator 0.
    ROM_PWMGenEnable(PWM0_BASE, PWM_GEN_0);

    // Enables (true) or disables (false) the specified PWM outputs
    ROM_PWMOutputState (PWM0_BASE, (PWM_OUT_1_BIT | PWM_OUT_0_BIT), true);

    MotorsInit();
    sprintf(stringbuffer, " \tPWM Motors\n\r");    send(stringbuffer);
    ROM_SysCtlDelay(16000000/10); //delay a little

// PWM Servo  ************************************************************************** LM4F232H5QD

    ROM_PWMGenPeriodSet(PWM0_BASE, PWM_GEN_1, 33333 );        // 60hz for servo motor
    ROM_PWMOutputInvert(PWM0_BASE, PWM_OUT_2_BIT, true);
    ROM_PWMPulseWidthSet (PWM0_BASE, PWM_OUT_2, 1990 );    // servo motor
    ROM_PWMGenEnable(PWM0_BASE, PWM_GEN_1);
    ROM_PWMOutputState (PWM0_BASE, PWM_OUT_2_BIT, true);

    sprintf(stringbuffer, " \tPWM Servo\n\r");    send(stringbuffer);
    ROM_SysCtlDelay(16000000/10); //delay a little

// *************************************************************************************************** LM4F232H5QD
// Initialize drive motors FORWARD/Reverse Direction control pins
// ***************************************************************************************************

    // Enable Port G for the on-board LED & H-bridge direction control - bits 6 & 2
    ROM_SysCtlPeripheralEnable(GPIO_PORTG_BASE);

    // Set bits 6 & 2 (PG2 right, PG6 left) motor FORWARD/reverse control. (PG2 also controls on board User LED).
    ROM_GPIODirModeSet(GPIO_PORTG_BASE, (GPIO_PIN_6  | GPIO_PIN_2 ), GPIO_DIR_MODE_OUT);

    // Set pin pads to standard TTL type using 2milliamp drive current
    ROM_GPIOPadConfigSet(GPIO_PORTG_BASE, (GPIO_PIN_6  | GPIO_PIN_2 ), GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD);

    // Enable the GPIO pin for digital output function.
    ROM_GPIOPinTypeGPIOOutput(GPIO_PORTG_BASE, (GPIO_PIN_6  | GPIO_PIN_2 ));

    ROM_SysCtlDelay(16000000/10); //delay a little
    sprintf(stringbuffer, " \tDirection\n\r");    send(stringbuffer);

    // *************************************************************************************************** LM4F232H5QD
    // Initialize ADC & the first sample sequencer to capture the values of channel 0 & 1
    // ***************************************************************************************************

    // Enable the ADC peripherals and the associated GPIO port
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_ADC0);

    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOE);

    // Configure the pins to be used as analog inputs.
    ROM_GPIOPinTypeADC(GPIO_PORTE_BASE, GPIO_PIN_3 | GPIO_PIN_2 | GPIO_PIN_1 | GPIO_PIN_0);

    // Select the external reference for greatest accuracy.
    ROM_ADCReferenceSet(ADC0_BASE, ADC_REF_EXT_3V);

    // Apply workaround for erratum 6.1, in order to use the external reference.
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);
    HWREG(GPIO_PORTB_BASE + GPIO_O_AMSEL) |= GPIO_PIN_6;

    ROM_ADCSequenceConfigure(ADC0_BASE, 0, ADC_TRIGGER_PROCESSOR, 0);

    ROM_ADCSequenceStepConfigure(ADC0_BASE, 0, 0, ADC_CTL_CH0);
    ROM_ADCSequenceStepConfigure(ADC0_BASE, 0, 1, ADC_CTL_CH1);
    ROM_ADCSequenceStepConfigure(ADC0_BASE, 0, 2, ADC_CTL_CH2);
    ROM_ADCSequenceStepConfigure(ADC0_BASE, 0, 3, ADC_CTL_IE | ADC_CTL_END | ADC_CTL_CH3);

    ROM_ADCSequenceEnable(ADC0_BASE, 0);

    ROM_ADCIntEnable(ADC0_BASE, 0);
    ROM_IntEnable(INT_ADC0SS0);

    ROM_SysCtlDelay(16000000/10); //delay a little
    sprintf(stringbuffer, " \tADC\n\r");    send(stringbuffer);

Cheers,

Dave

perhaps GPIO_PORTD_CR_R    &= ~0x08;        // Clear bit 7  to Re-lock

instead of

GPIO_PORTD_CR_R    &= !0x08;        // Clear bit 7  to Re-lock

might help?

Unless you're Euro based - you have similar "sleeping sickness" affliction as this reporter.

Still don't like your use of interrupt master disable - immediately after main.  Suggested that you review many of the code examples - (I did) could find none which employed that in such "brutal" fashion.  (it was always restricted - say w/in an interrupt handler)  Thus - should you still fault w/that function "commented out" - believe you have some problem.

Code dump is bit much - but some quick comments:

a) You attempt to "config & pin type" PD7 (dreaded NMI pin) long prior to your "unlock!"   Not too effective.  Later - (you note) you "re-do" - early attempt was wasted.

b) We've thus far avoided tivaware - note you often use directmodeset.  W'in Stellarisware - I find that gpiopintype() encapsulates directmodeset AND gpiopadconfig() - so seems superior.  (check if your xware allows)

c) Don't like elements of your PWM set-up/config - does your code generate the expected PWM?

d) I would (temporarily) bypass any/all QEI code - instead try to bring up one peripheral at a time - build confidence/understanding sequentially.  So much "in play" w/in QEI - and your past admittance of "manual avoidance" is sure to "bite you" when challenging this peripheral.

e) Your latest "unlock" reveals sleep disorder.  Earlier &= ~0x80 and |= 0x80 sure to "help" better than 0x08.  (targets PD3)

Again - believe it helpful/instructive to review sample code examples - see how/where interrupt master disable employed...  (we find - never as you've done...)