0
\$\begingroup\$

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:

hardware fault

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:

enter image description here

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.

Thanks in advance~~

\$\endgroup\$
12
  • 1
    \$\begingroup\$ 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. \$\endgroup\$ Feb 20 at 16:56
  • 1
    \$\begingroup\$ Are you sure it's not the watchdog that triggers? I can't see where you're initializing core stuff like the sysclk, watchdog, .... \$\endgroup\$
    – Seir
    Feb 20 at 17:12
  • 1
    \$\begingroup\$ @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... \$\endgroup\$ Feb 20 at 17:17
  • 1
    \$\begingroup\$ 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. \$\endgroup\$
    – Kartman
    Feb 20 at 17:22
  • 1
    \$\begingroup\$ 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. \$\endgroup\$
    – Seir
    Feb 20 at 17:34

1 Answer 1

1
\$\begingroup\$

I think you've configured the wrong MCU type.

enter image description here

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.

\$\endgroup\$
7
  • \$\begingroup\$ 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. \$\endgroup\$ Feb 20 at 18:00
  • 1
    \$\begingroup\$ 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'. \$\endgroup\$
    – Seir
    Feb 20 at 18:05
  • 1
    \$\begingroup\$ 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. \$\endgroup\$
    – Seir
    Feb 20 at 18:06
  • 1
    \$\begingroup\$ 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~~ \$\endgroup\$ Feb 20 at 18:19
  • 1
    \$\begingroup\$ I rarely ever used the FPU on this MCU. The driverib and SysCtlDelay work perfectly without having to init the FPU. \$\endgroup\$
    – Seir
    Feb 20 at 18:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.