# TM4C123GXL Tiva launchpad: Hardware Fault when debugging in Keil Microvision

I got a weird problem last night. Here is a simple program that uses pin PA7 to drive a LED:

#include <stdint.h>
#include <stdbool.h>
#include "driverlib/sysctl.h"
#include "inc/tm4c123gh6pm.h"

void PortA_Init(void){
volatile unsigned long delay;
SYSCTL_RCGC2_R |= 0x00000001;
delay = SYSCTL_RCGC2_R;
GPIO_PORTA_LOCK_R = 0x4C4F434B;   // 2) unlock PortA
GPIO_PORTA_CR_R = 0x80;           // allow changes to PA7
GPIO_PORTA_AMSEL_R = 0x00;        // 3) disable analog function
GPIO_PORTA_PCTL_R = 0x00000000;   // 4) GPIO clear bit PCTL
GPIO_PORTA_DIR_R |= 0x80;         // 5) PA7 output
GPIO_PORTA_AFSEL_R = 0x00;        // 6) no alternate function
GPIO_PORTA_DEN_R |= 0x80;         // 7) enable digital pins PA7
}

int main(void) {
PortA_Init();
while(1) {
GPIO_PORTA_DATA_R |= 0x80;
SysCtlDelay(500000);
GPIO_PORTA_DATA_R &= ~0x80;
SysCtlDelay(500000);
}
return 0;
}


When debugging in simulator (and real hardware), it is stuck in hardfault_handler section of startup.s. I Googled for a while and found out that I can check address 0xe000ed2s for additional bits:

From what I understand, 0x08 means that I have a NOCP error, according to this tutorial. However, I'm NOT using the FPU so I don't get where the error comes from:

I did some further tests and found something interesting. You can see that I'm using some header files under /driverlib. I also added the driverlib.lib file into the project, as shown in the pic below. However, this hardfault error is gone whenever I remove the #include "driverlib/sysctl.h line (as well as the SysCtlDelay() calls) from the source code. But I don't know why and how to fix. I still want to use this header file for further development.

• Can you use breakpoints and single-stepping to determine which statement is causing the fault? Debugging code by staring at it doesn't usually work, in my opinion. Feb 20 at 16:56
• Are you sure it's not the watchdog that triggers? I can't see where you're initializing core stuff like the sysclk, watchdog, ....
– Seir
Feb 20 at 17:12
• @Seir I just read the part about watchdogs, not sure but looks like it has to be initialized before being used. I don't intend to use them so I never initialize them, does it sound good? Anyway I never used them in my other projects before, hmmm... Feb 20 at 17:17
• Do a binary compare between the code that works vs what doesn’t. Hardware_fault suggests that you are accessing a peripheral that is not enabled and/or does not have its clock enabled. You can examine the stack to find the address where the fault occurred. That should give a hint as to what is wrong. Feb 20 at 17:22
• Nothing wrong using registers directly when you need to do some fancy stuff. But I'd recommend you use the driverlib for GPIO config and access.
– Seir
Feb 20 at 17:34

I think you've configured the wrong MCU type.

The TM4C123GXL Tiva launchpad has a TM4C123GH6PM MCU.
The driverlib expects a TM4C1231C3PM, but it's actually a TM4C123GH6PM.

That's probably the reason the driverlib causes a NOCP fault, because some core registers have to be setup differently.

• Thanks @Seir, I noticed that issue long ago, but somehow my previous programs compiled and ran fine using either SFR file. BTW I also tested the error program using TM4C123GH6PM but it shows the same error. Feb 20 at 18:00
• I'm not talking about the SRF file. It was just the means that I found out your MCU configuration is faulty. Never be content with 'somehow it ran fine in the past'.
– Seir
Feb 20 at 18:05
• I use Code Composer Studio myself, so I can't help you where exactly you need to configure your MCU within Keil. But seriously, you have to configure the correct MCU, otherwise there be dragons.
– Seir
Feb 20 at 18:06
• Thanks @Seir I agree with you. BTW l seems to find (part of) the issue: Looks like the driverlib files are not compatible with the specific hardware. I downloaded a different copy from TI and comment out the SysctlDelay() lines and now it at least blinks the LED. However, adding SysCtlDelay() back still triggers the hardfault. So I think maybe the library uses FPU and I need to initialize it first. I'll read the document for the driver library to figure out, thanks again for the help~~ Feb 20 at 18:19
• I rarely ever used the FPU on this MCU. The driverib and SysCtlDelay work perfectly without having to init the FPU.
– Seir
Feb 20 at 18:22