This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

HardFault is triggered when running PWM module

Other Parts Discussed in Thread: TM4C123GH6PM

Hi, All,

I am using Tive TM4C123GXL EVB with Keil MDK-ARM u5 to build a PWM program. Sometimes the HardFault event is triggered and enter the break point in the HardFault_Handler when the project is running. The codes are shown below:

#include <stdint.h>
#include <stdbool.h>
#include "inc\tm4c123gh6pm.h"

void Delay(uint32_t time);

int main(void)
{
 int pw;
 
 SYSCTL_RCGCPWM_R |= 0x2;          // enable PWM1 with clock
 SYSCTL_RCGCGPIO_R = 0x20 | 0x02;
 SYSCTL_RCC_R = SYSCTL_RCC_USEPWMDIV|SYSCTL_RCC_PWMDIV_2;
 SYSCTL_RCGC0_R |= SYSCTL_RCGC0_PWM0;    // enable PWM1 again
 
 // PWM1_2B - PF1 - M1PWM5 pin - Module 1 Generator 2
 PWM1_2_CTL_R = 0x0;             // disable PWM1_2B or M1PWM5
 PWM1_2_GENB_R = 0x0000080C;
 PWM1_2_LOAD_R = 3999;
 PWM1_2_CTL_R = 0x1;             // enable PWM1_2B or M1PWM5
 PWM1_ENABLE_R = 0x20;            // enable PWM1
 
 GPIO_PORTF_DIR_R |= 0x02;
 GPIO_PORTF_DEN_R |= 0x02;
 GPIO_PORTF_AFSEL_R |= 0x2;         // PF1 - Alternate Function: PWM1-2B
 GPIO_PORTF_PCTL_R |= GPIO_PCTL_PF1_M1PWM5; // 0x00000050
 GPIO_PORTB_DIR_R |= 0x03;          // enable PB1, PB0 output pins
 GPIO_PORTB_DEN_R |= 0x03;          // enable PB1, PB0 digital function pins
 GPIO_PORTB_DATA_R |= 0x01;         // enable PB0 (AIN1=1) CW-rotation
 
 while(1)
  {
  for (pw = 100; pw < 3999; pw += 20)
    {
       PWM1_2_CMPB_R = pw;
       Delay(50000);
    }
    for (pw = 3999; pw > 100; pw -= 20)
    {
       PWM1_2_CMPB_R = pw;
       Delay(50000);
    }
    GPIO_PORTB_DATA_R |= 0x01;
    for (pw = 100; pw < 3999; pw += 20)
    {
       PWM1_2_CMPB_R = pw;
       Delay(50000);
    }
    for (pw = 3999; pw > 100; pw -= 20)
    {
       PWM1_2_CMPB_R = pw;
       Delay(50000);
    }
    GPIO_PORTB_DATA_R |= 0x01;
  }
}

void Delay(uint32_t time)
{
 uint32_t Loop;
 for (Loop = 0; Loop < time; Loop++) {}
}

  • Hello Ying,

    The issue is with the manner in which the clock is enabled

     SYSCTL_RCGCPWM_R |= 0x2;          // enable PWM1 with clock
     SYSCTL_RCGCGPIO_R = 0x20 | 0x02;
     SYSCTL_RCC_R = SYSCTL_RCC_USEPWMDIV|SYSCTL_RCC_PWMDIV_2;
     SYSCTL_RCGC0_R |= SYSCTL_RCGC0_PWM0;    // enable PWM1 again

    I believe the Fault Status will be showing that the fault address is PWM-1

    The actual code should be

     SYSCTL_RCGCPWM_R |= 0x2;          // enable PWM1 with clock
     SYSCTL_RCGCGPIO_R = 0x20 | 0x02;
     SYSCTL_RCC_R = SYSCTL_RCC_USEPWMDIV|SYSCTL_RCC_PWMDIV_2;

    On top of it, please void Direct Macro's, instead using TivaWare (it will simplify the development)

    Regards

    Amit

  • Amit,

    thanks for your prompt reply.

    However, I am developing my project with two methods; the direct register access method and software driver method. Therefor I have to use the direct macros.

    I think that I have found solution for this bug. The GPIO port F lock and CR registers should be taken care Even in normal cases they should be configured correctly after a reset. But in cases, additional care should be taken. After I handled this issue, the problem seems to be solved. I testing 10 times with no problem.

    anyway, thanks for your help.

    by the way, I also checked to enable FPU.

  • Amit,

    Another way to make the project to work is to add a blank fault handler. The project can continue to work even this fault occurred.

  • Umm, how about no. I suggest you stop whatever you're doing right now and learn why that is a very, very bad idea. Those faults do occur for a reason, you shouldn't just ignore them.

  • Please see my last email for the solution to this bug.

     

  • Veikko Immonen said:
    Umm, how about no.

    Bravo Veikko!

    Can poster say, "House of Cards?"  

    I can avoid my sports car's temperature gauge signaling "over-heating" with a similar, "empty fault handler!" (i.e. a post-it blocking the offending gauge)  But I won't...

  • This problem has been solved. Please see my last email before this email. This email is giving an optional way to make project running. If you do not like this way, you can use the method in my previous email to remove this bug. When you read my all emails, please open your eye.

     

  • The problem is that your optional solution (the empty fault handler) is an absolute no-no, and that has been now marked as the verified answer. Thus I think it's important to point out that it is not the way to go, just in case someone not familiar with these things comes to this thread for an answer.

    I'm not commenting (nor going to) on your other solution.

  • Hello Ying

    I would agree with Veikko, An empty fault handler is not a good solution to make the device work. The Fault Handler has a specific purpose in the system. While it has worked now by doing an "empty fault handler", image a instruction fault or a imprecise data abort. The code will simply go in an uncontrollable loop. It would be days before you would figure out the actual cause,

    Regards

    Amit

  • Amit,

    Please do not be confused about this second option. You know that this problem has been solved and this second is only for an option. Anyway, anybody can do anything what he/she wants since that is beyond my control.

    However, this fault is not a serious one since the program can work normally with this empty fault handler. I know that we should fix this bug even it is not a serious. But this bug HAS BEEN FIXED in my previous email or post on this board. I cannot undestand why somebody never pay any attention to my solution but catch this issue in an abnormal way.

    Anyway, thansk for your idea and talk to you later.