Compiler/EK-TM4C123GXL: Fault isr problem

The combination of your, "Being rusty in C" and then rejecting the vendor's exacting API in favor of the far more demanding "Direct Register Manipulation (DRM)" works "Not so much" in your favor.

This being your very first post IS noted - thus you could not know of this vendor's "Stated reluctance to engage posters in DRM or ASM (assembly) code analysis."    (this as the time, effort required greatly increases - while benefits accrue to so (very) few.)     (Most everyone of (pardon) "sound mind" employs the uber efficient (time, labor saving) API)

Note too that we "Non vendor/occasional helpers" - equally prefer not to spend such great time/effort scanning thru such, "Detailed Register bit descriptions" when such has (very) effectively been done (by experts) - and is efficiently encapsulated w/in vendor's comprehensive API.    That API is "Tried, True, Endlessly Proven" - such can "Never be said" for "individual DRM or ASM efforts" (always & forever suspect) - thus, "What is the point?"

You write of a "qti" sensor - might you have intended "QEI" (Quad Encoder Interface) instead.    (such "loss of focus" often is the result of "deep/distracting dive into DRM/ASM code.")     (Not to ask - HOW I know...)

As your code is short - might you set "break points" and determine - then report - which of the code lines, "Drives into the dreaded "Fault ISR?"     Myself (& others) are not thrilled by the form of your 1st "while."

Hello Raza and welcome to the TM4C  microcontroller forum.

First,  let me say that I completely agree with CB1 (and greatly appreciate is help) when he recommends using the TivaWare API instead of writing directly to the registers. You will find great advice from long time volunteers like CB1 on this forum.

As a second suggestion, please click on "Inset Code, Attach Files and more..." when you want to insert code into your post. Then use the </> button to paste your code. That way it keeps the formatting which makes it much easier to read. It will look like this:

#include <stdint.h>
#include <stdbool.h>
#include "inc/hw_types.h"
#include "inc/hw_memmap.h"
#include "driverlib/sysctl.h"
#include "driverlib/gpio.h"
#include "inc/tm4c123gh6pm.h"
#include <stdio.h>


void PORTB_Init (void){
    SYSCTL_RCGCGPIO_R|=0X01; //enable clock for port b
    while((SYSCTL_PRGPIO_R&0X01) == 0 ){}; //ready??
    GPIO_PORTB_CR_R |=0X20; //allow CHANGES TO PORT B5 0010 0000
    GPIO_PORTB_DEN_R |=0X20; // ENABLE DIGITAL i/o ON PB5

}



int main(void)
{
    volatile uint32_t data;
    while(1){

        GPIO_PORTB_DIR_R |=0X20; //PB5 OUT
        GPIO_PORTB_DATA_R |=0x20; // make pb5 high
        SysCtlDelay(1000000);
        GPIO_PORTB_DIR_R &= ~0X20; //PB5 input

        SysCtlDelay(1000000);
        GPIO_PORTB_DATA_R=data;


        SysCtlDelay(50);

    }


}

And finally, I noticed that you wrote the function to initialize GIO port B, but never called it. Therefore in main you tried to write to a port B register without enabling the clock to this peripheral. That causes a data abort which takes you to the endless loop.

Bob Crosby said:

I noticed that you wrote the function to initialize GIO port B, but never called it.

OMG Bob - je suis un idiot!      Well noted - only (and pathetic) defense I can throw up is, "distraction via DRM."     (DRM gives - and "keeps" giving...)

I did note that poster enabled the clock to Port_B - yet (completely) MISSED the fact that his main() "Failed to call that init."    (mortifying after such nice (& appreciated) words...)

Raza,

If you follow the advice of CB1 to use the API, your code would look something like this:

#include <stdint.h>
#include <stdbool.h>
#include "inc/hw_types.h"
#include "inc/hw_memmap.h"
#include "driverlib/sysctl.h"
#include "driverlib/gpio.h"
#include "inc/tm4c123gh6pm.h"
#include <stdio.h>


void PORTB_Init (void)
{
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);
    while(!SysCtlPeripheralReady(SYSCTL_PERIPH_GPIOB))
    {
    }
}



int main(void)
{
    volatile uint32_t data;

    PORTB_Init();
    while(1)
    {
        GPIOPinTypeGPIOOutput(GPIO_PORTB_BASE, GPIO_PIN_5); //PB5 OUT
        GPIOPinWrite(GPIO_PORTB_BASE, GPIO_PIN_5, GPIO_PIN_5); // make pb5 high
        SysCtlDelay(1000000);
        GPIOPinTypeGPIOInput(GPIO_PORTB_BASE, GPIO_PIN_5); //PB5 input
        SysCtlDelay(1000000);
        data = GPIOPinRead(GPIO_PORTB_BASE, GPIO_PIN_5);
        SysCtlDelay(50);
    }
}

Again - "Above & Beyond" Bob - most excellent.     (it proves more usual to just note, "Do not use DRM" - and leave the post at that...)     Noted too is your (more) proper format of the initial "while."

Now - may it be noted that poster seeks to, "Toggle the same pin between Output & Input."     And - depending upon the impedance of the external signal (introduced as "input" to poster's MCU) - "Output Contention may arise!"      It must be assured that the "external signal" - if sufficiently low in impedance - does not arrive while the MCU is attempting to Output!     (such may prove damaging to the MCU - or the external device - and sometimes (even) to both!) ... ... (i.e. Smoke ++;)

May I suggest that poster - at such early stage - employ different pins for (both) Output & Input Testing.

In the (relatively) rare case that poster targets a, "One Wire" external device - by definition - "low (thus damaging) impedances" are prevented...

Thanks for your comprehensive reply yes I understand using API is much more effecient. However I wanted to understand hardware architecture thus started from low-level programming. I understand it is distracting and as a result missed to call the function in main.

Thank you - yet often the claim is made that (only) thru "low-level programming" is the hardware architecture "understandable."

Having long employed (w/some success) these/similar MCUs - it proves (always) unclear (and unconvincing) why & how - "such in depth Register Bit review" - provides (greater) insight into hardware!    It is well known that these MCUs provide multiple, 32 bit wide Registers - but (again) how does the "overly demanding" review of multiple registers - and their key bits - provide "insight into hardware architecture?"    It is doubted that you - or others - can make such a case!     (I've never seen anyone here - even try!)

Note too - that employing the API - "Speeds, Eases & Enhances" your CONTROL of the hardware - which indeed "BOOSTS" understanding.     Your use of DRM - due to the necessity to comb thru various Register "fine details" (none of which define/describe hardware - yet alone "architecture") caused both you & I to "miss" that "missed "init call."     Bob - freed from the "DRM Rejection" (which I supplied) proved better able to "absorb the code error.")    Again - such forced "distraction" (wrought by DRM) provided little understanding - instead caused MANY to "arrive here - seeking help."

Nothing prevents one from examining the API's Source Code - which details not only Registers and their key bits - but also provides the optimal "Sequence of Register Usage - and Bit Settings - which (may) impart better understanding of hardware relationships...      And is notably absent w/in DRM/ASM!

While (many) like you have proclaimed, "low-level as promoting hardware understanding" - none here have made ANY case in support of such claim!   Instead of "understanding" - the usual result is "crash/burn" - which somehow runs FAR counter to any claim of heightened "understanding!"

Serious (studied) review of the MCU Manual - both from documents here and the many forum postings & examples - likely provides a far better means to, "Understand the hardware architecture..."