TM4C123GH6PM: help needed in tivaware

sarea hariri

Hi all,

I am trying to connect 2 of tm4c123 launchpad using uart1 module on the both. the application i use is so simple, pressing switch on one launchpad >> turn led on on the other launchpad.

the problem is that i configured the settings such that it will interrupt on the falling edge for sw1 and sw2 of launchpad (PF0, PF4) but i found that the interrupt still occurring on the falling edge of PF1, PF2, PF3.

here is the port f initialization:

void PORTF_Init(void){
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF) ;
    while(!SysCtlPeripheralReady(SYSCTL_PERIPH_GPIOF)) ;

    GPIO_PORTF_LOCK_R = 0x4C4F434B ;
    GPIO_PORTF_CR_R |= 0x01 ;
    GPIOPinTypeGPIOInput(GPIO_PORTF_BASE, GPIO_PIN_0|GPIO_PIN_4) ;

    GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3) ;

    GPIOPadConfigSet(GPIO_PORTF_BASE, GPIO_PIN_0|GPIO_PIN_4, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD_WPU) ;

    GPIOIntTypeSet(GPIO_PORTF_BASE, GPIO_INT_PIN_0|GPIO_PIN_4, GPIO_FALLING_EDGE) ;

    GPIOIntRegister(GPIO_PORTF_BASE, PORTF_isr) ;

    GPIOIntEnable(GPIO_PORTF_BASE, GPIO_INT_PIN_0|GPIO_INT_PIN_4) ;


}

any one can help ?

thanks,

Sarea

over 8 years ago

0 cb1_mobile over 8 years ago

Guru 117855 points

sarea hariri said:
i found that the interrupt still occurring on the falling edge of PF1, PF2, PF3.

It should be noted that you've "configured PF1, PF2, & PF3 as outputs" - in light of that fact - do PF1-PF3 (really) generate the (PinInt constrained) Port_F interrupt? Have you checked, recently?

In addition - you employ, "GPIOIntEnable()" - should not that be: "GPIOPinIntEnable()?" (this "PinInt" function (I believe) yields the "more selective" (Port PIN) interrupts you seek. (under past StellarisWare)

Best practice would see you employ: "IntDisable()" followed by "GPIOPinIntDisable()" prior to your other Port F interrupt calls!

Again - I believe your use of "GPIOPinIntEnable()" will "confine your interrupts to those listed w/in that function call - resolving your issue...

Below is "working, model Port Pin Interrupt Config. code" (developed under StellarisWare 9453 - required by our clients) which (hopefully) illustrates/clarifies. (TivaWare may dictate (some/slight) changes...)

ROM_GPIOPinTypeGPIOInput(PIN_Target_PORT, (PIN_TargetA_PIN | PIN_TargetB_PIN | PIN_TargetC_PIN));

ROM_GPIOPadConfigSet(PIN_Target_PORT, (PIN_TargetA_PIN | PIN_TargetB_PIN | PIN_TargetC_PIN));, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD_WPU);

ROM_GPIOIntTypeSet(PIN_Target_PORT, (PIN_TargetA_PIN | PIN_TargetB_PIN | PIN_TargetC_PIN)); GPIO_BOTH_EDGES);

and then:

ROM_IntDisable(INT_GPIOF); // adapt "INT_GPIOF" as required - to suit "TivaWare"

ROM_GPIOPinIntDisable(PIN_Target_PORT, (PIN_TargetA_PIN | PIN_TargetB_PIN | PIN_TargetC_PIN)); // we've uniquely defined "PIN_Target_PORT & PIN_Target(n)_PIN"

ROM_GPIOPinIntClear(PIN_Target_PORT, (PIN_TargetA_PIN | PIN_TargetB_PIN | PIN_TargetC_PIN));

ROM_GPIOPinIntEnable(PIN_Target_PORT, (PIN_TargetA_PIN | PIN_TargetB_PIN | PIN_TargetC_PIN));

ROM_IntEnable(INT_GPIOF); // adapt "INT_GPIOF" as required - to suit "TivaWare"

Note our preference (by far) is to "Embed the ISR's name w/in the Start-Up file - thus avoiding any requirement to "register" the interrupt. (i.e. RAM devouring)

Purists would prefer you to use "MAP" rather than ROM calls...

0 sarea hariri over 8 years ago in reply to cb1_mobile

Intellectual 650 points

Sir,
PF1-PF3 generate interrupts on falling edges .. i check that in RIS register ( using single stepping in CCS ).
Secondly, there is no function in the tivaware package i use has the "GPIOPinIntDisable()" prototype ..
In addition, tm4c123 allows us to use only one ISR for the entire port as i think and so, i should check RIS in the ISR to find the pin that caused the interrupt.

Thanks,
Sarea

0 cb1_mobile over 8 years ago in reply to sarea hariri

Guru 117855 points

Thank you - I've added a code example to my (earlier) post. Accept that the code provided has worked on "several thousand" shipped boards!

Note that your, "check of RIS - w/in the Port ISR" is both clever & correct. That said - the function "PinInt()" (abbreviated) attempts to limit - thus reduce - the number of pins able to impact RIS. (that's a "good thing" - is it not?)

As stated - clients (demand) our use of the "more proven/stable" StellarisWare - you must find the "most appropriate function" (i.e. best match) under your version of "vendorWare."

You make no mention - nor note - of my suggestion re: "GPIOPinIntEnable()" - entirely absent from your code! And which aims to allow (your desired) individual PIN Interrupts! Why is that?

Should you make the effort to respond to:

lack of (any) mention of "GPIOPinIntEnable()" - which I believe to prove "vital"

and

can PF1-PF3 - configured by you (revealed by your code) as Outputs - (really) generate (PinInt constrained) Port_F interrupts?

I will - in turn - find the time to "compare/contrast" past StellarisWare w/vendor's (pardon) buggy newer version - seeking best match - in your behalf. You can, "Speed, Ease, Enhance" my efforts by (first) conducting your search under your API - seeking past match to the functions I've noted. Our firm is presently "moving our external warehouse" past 2 days have seen (record) heat (>94°F) in Chicago (USA) and we are "back at it" (yes - even on Sat & Sun) so my return will be "late in the day..." (again - under the proviso that you respond as requested - which proves quite fair - does it not?)

0 sarea hariri over 8 years ago in reply to cb1_mobile

Intellectual 650 points

Sir,

About your code and functions like " GPIOPinInt***() " prototype:

There is NO function in tivaware that disable or enable the interrupt on the pin level (individually) ..all functions i have are on the entire port .

But i think i can trigger the port f interrupt based on certain pins only using the "GPIOIntTypeSet(...)" function .. since the second parameter specify the desired pins used for triggering as i know .. so why PF1-PF3 still generate interrupts on the falling edges even that i DON'T pass them in the second parameter ??

I hope that my question is clear.

Thanks

Sarea

0 Charles Tsai over 8 years ago in reply to cb1_mobile

TI__Guru**** 191886 points

Hi cb1,
Thanks for sharing your example code. In the TivaWare driver library the GPIOIntEnable is now used instead of GPIOPinIntEnable().

Hi Sarea,
I don't really spot anything wrong with your code. Please open the register browser window and examine the registers like GPIODIR, GPIOIS, GPIOIBE and GPIOIM. Are PF1,2,3 really configured as output? What are the interrupt masks for them? Compare the setting for PF1,2,3 against the PF0,4 in those registers. I just can't think of a reason why PF1,2,3 will generate interrupts if they are configured as outputs. Please also follow cb'1 suggestion to first clear all interrupt flags before enabling interrupts for pins 0,4.

As an experiment, what if you comment out the line GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3). Do you still see the RIS flags set for them

0 cb1_mobile over 8 years ago in reply to sarea hariri

Guru 117855 points

sarea hariri said:
There is NO function in tivaware that disable or enable the interrupt on the pin level (individually) ..all functions i have are on the entire port .

That sentence of yours is "outstanding" - very good job - a perfect summary! Very well done!

That said - can you (perhaps others, too) NOW understand, "Why my firm's "Key Clients" have insisted that we employ (only) StellarisWare 9453?" (which was known as "bug-free and stable!" - while supporting LM3S and LX4F AND TM4C123. (w/very minor modification (pin_map.h))

Indeed some (neat) functions have been added - yet "stability & robustness" have GREAT importance - and have dictated our choice.

Dawns that my suggestion of your/others' use of "GPIOPinIntEnable()" - if indeed absent from newer API - may be "created" - and that effort is eased by review of the past source code.

Here then - that source code: (property of this vendor - yet in the public domain)

//*****************************************************************************
//
//! Enables interrupts for the specified pin(s).
//!
//! \param ulPort is the base address of the GPIO port.
//! \param ucPins is the bit-packed representation of the pin(s).
//!
//! Unmasks the interrupt for the specified pin(s).
//!
//! The pin(s) are specified using a bit-packed byte, where each bit that is
//! set identifies the pin to be accessed, and where bit 0 of the byte
//! represents GPIO port pin 0, bit 1 represents GPIO port pin 1, and so on.
//!
//! \return None.
//
//*****************************************************************************
void
GPIOPinIntEnable(unsigned long ulPort, unsigned char ucPins)
{
//
// Check the arguments.
//
ASSERT(GPIOBaseValid(ulPort));

//
// Enable the interrupts.
//
HWREG(ulPort + GPIO_O_IM) |= ucPins;
}

//*****************************************************************************
//
//! Disables interrupts for the specified pin(s).
//!
//! \param ulPort is the base address of the GPIO port.
//! \param ucPins is the bit-packed representation of the pin(s).
//!
//! Masks the interrupt for the specified pin(s).
//!
//! The pin(s) are specified using a bit-packed byte, where each bit that is
//! set identifies the pin to be accessed, and where bit 0 of the byte
//! represents GPIO port pin 0, bit 1 represents GPIO port pin 1, and so on.
//!
//! \return None.
//
//*****************************************************************************
void
GPIOPinIntDisable(unsigned long ulPort, unsigned char ucPins)
{
//
// Check the arguments.
//
ASSERT(GPIOBaseValid(ulPort));

//
// Disable the interrupts.
//
HWREG(ulPort + GPIO_O_IM) &= ~(ucPins);
}

Note that vendor claims that (past) LX4F is essentially replicated by TM4C123 - and firm/I have confirmed that this past code SUCCEEDS (both) upon LX4F AND TM4C123!

As the code is SO limited - it is hard to understand "why" this has been "bypassed" - and appears (relatively) easy to "graft into" your (unique) version of vendorWare. (as new versions arrive - this addition will be "lost" - that choice resides w/the user...

You may wish to "try this" (especially in light of this (so short) source listing) and report your results...

0 sarea hariri over 8 years ago in reply to cb1_mobile

Intellectual 650 points

Hi Charles and cb1,
Finally i found the bug.. i used the "GPIOIntStatus(**, **)" wrongly in the main. That is i passed the second parameter "false" instead if "true".
The function will return raw interrupt status or masked interrupt status for " false " or "true" passed as a second parameter respectively.

But here i have a new question .. why does the RIS register rise a flag on the PF1, PF2 and PF3 when falling edges occurred even if i use " GPIOIntTypeSet(**,**,**)" with only PF0 | PF4 passed as a second parameter( the code included in original post).

Thanks and Regards,
Sarea

0 Charles Tsai over 8 years ago in reply to sarea hariri

TI__Guru**** 191886 points

Hi Sarea,
It is a bit weird that the hardware behaves as you described. Currently I don't have the bench setup at home to run experiments. Can you first confirm the setting in the GPIODIR register from the perpheral browser window? What does it say? Perhaps you can take screen shot of all the GPIO registers and show us.

Have you done any writes to the PF1,2,3 pins in your ocde? Is there anywhere in your code where you change the pin direction again for PF port? What if you comment out the line GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3). Do you still see the RIS flags set for them?

0 cb1_mobile over 8 years ago in reply to Charles Tsai

Guru 117855 points

I'd "LIKE" the above post - should that capability have (been allowed) to continue.

The identification by vendor's Charles of: "PF writes, PF config changes, and PF output deletion" serves in fact as a prime illustration of the (also) banned "KISS" - which "Speeds, Eases, Enhances" design & development by restricting operations to ONLY those, "most specific & simple..." Adding to this mix - as Charles has noted - has the potential to add "issues & complications" - and should be avoided!

Arm-based microcontrollers

Arm-based microcontrollers forum

TM4C123GH6PM: help needed in tivaware