TM4C123 QEI

Jay Bu1 said:

The ROM based function doesn't work.

How do you know that?

Regards,
Maciej 

The code snippet that you have provided only shows configuration of the GPIO signals to be used for QEI operation.  It does not show any configuration of the QEI peripheral.

When you say "doesn't work", are you referring to the GPIO configuration, or the QEI operation in general?

--Bobby

Jay Bu1 said:

ROM_GPIOPinConfigure(GPIO_PD7_PHB0);

Believe that this function, "will not work."  And that because PD7 "normally" defaults into NMI (on many/most) LX4F and new rebrand series...

PD7 is "protected" - must first be unlocked - and then may be re-purposed.  (to QEI - in your case)

Precision/surgical description, "doesn't work" - your opinion at best - usefulness to remote helpers minimal...

MCU detailed manual fully describes "unlock procedure" - enabling harvesting of default pins...

The ROM functions work fine for the PWM. However, they don't work for the QEI. You can verify it by inspecting the registers.

OK, I attach the whole my QEI configuration program. As you can notice, I comment out the ROM function. In stead I directly access the register for configuration. I used the ROM function for PWM configuration, it works. In the QEI configuration, ROM function didn't change the GPIO registers. You can verify it from the ccs.

SysCtlPeripheralEnable(SYSCTL_PERIPH_QEI0);

// Enable GPIO ports that are configured for QEI
SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);
SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);

// Commit for PD7
HWREG(GPIO_PORTD_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY;
HWREG(GPIO_PORTD_BASE + GPIO_O_CR) = GPIO_LOCK_LOCKED << 7; // The define!
// GPIO_PORTD_LOCK_R = GPIO_LOCK_KEY;
// GPIO_PORTD_CR_R = GPIO_LOCK_LOCKED;

GPIO_PORTD_AFSEL_R = ( GPIO_PORTD_AFSEL_R | 0x0C0 );
GPIO_PORTF_AFSEL_R = ( GPIO_PORTF_AFSEL_R | 0x010 );

GPIO_PORTD_PCTL_R = ( GPIO_PORTD_PCTL_R | 0x66000000 );
GPIO_PORTF_PCTL_R = ( GPIO_PORTF_PCTL_R | 0x00060000 );

// The ROM function doesn't work!
// ROM_GPIOPinConfigure(GPIO_PF4_IDX0);
// ROM_GPIOPinConfigure(GPIO_PD6_PHA0);
// ROM_GPIOPinConfigure(GPIO_PD7_PHB0);

// ROM_GPIOPinTypeQEI(QEI0_BASE,GPIO_PIN_4);
// ROM_GPIOPinTypeQEI(QEI0_BASE,GPIO_PIN_6);
// ROM_GPIOPinTypeQEI(QEI0_BASE,GPIO_PIN_7);

HWREG(GPIO_PORTD_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY;
HWREG(GPIO_PORTD_BASE + GPIO_O_CR) = GPIO_LOCK_UNLOCKED;
HWREG(GPIO_PORTD_BASE + GPIO_O_LOCK) = GPIO_LOCK_M;

ROM_QEIConfigure(QEI0_BASE,QEI_CONFIG_CAPTURE_A_B|QEI_CONFIG_NO_RESET|QEI_CONFIG_QUADRATURE|QEI_CONFIG_NO_SWAP, 0x0FFFFFFFF);

ROM_QEIEnable(QEI0_BASE);

I made the commit for PD7. I did the same commit in my PWM configuration. The ROM function work fine for the PWM configuration. For the QEI, you'd better to verify it by inspecting the registers directly. After the ROM function, there are no changes in the related registers. 

I find the problem.

When calling:

ROM_GPIOPinConfigure(x);
ROM_GPIOPinTypePWM(x);

The functions configure ASEL, DEN and other related registers based on the PWM port requirement. However, as ROM_GPIOPinConfigure(x)/ROM_GPIOPinTypeQEI(x) DIDN'T work for the QEI port. I access the registers directly through following codes.

GPIO_PORTD_AFSEL_R = ( GPIO_PORTD_AFSEL_R | 0x0C0 );
GPIO_PORTF_AFSEL_R = ( GPIO_PORTF_AFSEL_R | 0x010 );

GPIO_PORTD_PCTL_R = ( GPIO_PORTD_PCTL_R | 0x66000000 );
GPIO_PORTF_PCTL_R = ( GPIO_PORTF_PCTL_R | 0x00060000 );

In the above code, I haven't change the DIR and DEN registers.  After adding the configuration for  the DIR and DEN registers, the QEI port works.

Our posts landed here together - to the exact minute.  Glad you persisted - found the problem - and shared a workable solution.

Only other function I know which has "not yet" made it into LX4F ROM is: "GPIOPinTypeI2CSCL()" - so your report (if valid) will be useful to others.

Note that indeed you did far better describe your issue (i.e. QEI Registers did not properly follow ROM based functions) - commend you for that.

Will be interesting if factory can/will confirm your findings - we have different LX4F - if time allows will replicate your test & report here...

Suppose some case could be made for, "failure of IDE/StellarisWare" to note invocation of "invalid" function call - "inventive discovery" - as you did - bit much to expect from average user.  Believe that you did a very good job - applaud that effort and your sharing it to the benefit of others.  Thank you.

Thanks a lot. It definitely is an overlook. I'll try this though my QEI is already working now.

Bobby found the source of the problem. I put a wrong base address in the ROM function ( an overlook). I'll verify it later though my QEI is already functioning. Thanks.

Good job Bobby - much appreciated.

Mystery here (to our group) is how poster concocted, "ROM_GPIOPinTypeQEI(QEI0_BASE, ...)

For the record - I list here most (all) of the legal parameters - function ROM (or non-ROM) GPIOPinType...

extern void GPIOPinTypeI2C(unsigned long ulPort, unsigned char ucPins);
extern void GPIOPinTypeI2CSCL(unsigned long ulPort, unsigned char ucPins);
extern void GPIOPinTypeI2S(unsigned long ulPort, unsigned char ucPins);
extern void GPIOPinTypeLPC(unsigned long ulPort, unsigned char ucPins);
extern void GPIOPinTypePECIRx(unsigned long ulPort, unsigned char ucPins);
extern void GPIOPinTypePECITx(unsigned long ulPort, unsigned char ucPins);
extern void GPIOPinTypePWM(unsigned long ulPort, unsigned char ucPins);
extern void GPIOPinTypeQEI(unsigned long ulPort, unsigned char ucPins);
extern void GPIOPinTypeSSI(unsigned long ulPort, unsigned char ucPins);
extern void GPIOPinTypeTimer(unsigned long ulPort, unsigned char ucPins);
extern void GPIOPinTypeUART(unsigned long ulPort, unsigned char ucPins);
extern void GPIOPinTypeUSBAnalog(unsigned long ulPort, unsigned char ucPins);
extern void GPIOPinTypeUSBDigital(unsigned long ulPort, unsigned char ucPins);

Note that in each/every case - first parameter is ulPort - and that poster's "QEI0_BASE" - while inventive - is not a legal/recognized parameter!

As earlier stated - should not the IDE have "squawked" - alerting poster to this unfortunate construct?  (suppose that it may have - and that feedback suppressed)

And - even if correct parameter was supplied - failure to recognize the necessity to first "unlock" PD7 (as early highlighted by this reporter) would have doomed efforts...