Hard Fault Problem after initializing the GPIO PB5 interrupt

Hello Curtis,

Can you add the following check

while(!SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB));

after enabling the peripheral. If that resolves the issue do let me know then I can explain what happened.

The other comment that if you step again it immediately goes into hard fault is not very clear? Can you explain this and while you check, could you check the NVIC_FAULTSTAT and NVIC_FAULTADDR registers at 0xE000ED28 and 0xE000ED38

Regards

Amit

Hey Amit,

I think you made a mistake with the code you suggested.  SysCtlPeripheralEnable doesn't return anything (void).  So instead I figure you meant to use either SysCtlPeripheralReady or SysCtlPeripheralPresent which both return a boolean value.  However neither of those helped.  The program just ran through both of them and ended up in the hard fault handler (FaultISR) again.

What I meant earlier is that as I step through the debugger I get to that last line of code in that function which is

IntEnable(INT_GPIOB);

I then hit "step over" in the debugger again but instead of returning to the main code execution it ends up in the hard fault handler instead.  It actually just continues running after I hit "step over" and then when I hit pause it shows that I;m stuck in the hard fault handler's infinite loop.

Here are the memory adresses you requested:
Name                            Address               Value
NVIC_FAULTSTAT      0xE000ED28      0x00000400
NVIC_FAULTADDR    0xE000ED38      0xE000EDF8

Regards,
Curtis

Hello Curtis

Yes, I actually meant using SysCtlPeripheralReady. That was a mistake on my side. Now after making the correction it still gives the same values in the FAULTSTAT?

The error is shows that it is a IMPRE data bus fault. Also as mentioned this happens only when PLL is locked and not when the System Clock is same as PIOSC? Could you check if this happens when the System Clock is XTAL.

Regards

Amit

Hey Amit,

"Also as mentioned this happens only when PLL is locked and not when the System Clock is same as PIOSC?"

I'm not sure what you mean with the question above.  I don't think you or I mentioned that before.  

The value in FAULTSTAT is the same regardless of whether or not that line is included.

Regards,
Curtis

Hello Curtis,

I was quoting the following line from the first post

I use this same exact initialization and interrupt handler previously and it works just fine.  Previously I was just reading data from an ADC and then scaling it  before outputting it to a DAC.  I have now added code for a PLL and it is hard faulting where it worked previously.

Regards

Amit

What do you want me to change the following line to?

ROM_SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN | SYSCTL_XTAL_16MHZ);

I really need to be able to run it at the full 80 MHz for my application.  As far as I know this setting is the only way to get it to run at 80 MHz.  I can try something else just to see if it helps if you have a suggestion.

Regards,

Curtis

Hey Amit,

What I meant by that was that I had another program previously where that same code wasn't giving me the fault.  The program that works is in the folder attached to the original post It is in the sub-folder named "Working Test Code".  The name of the file is "GTBE_mainTestDRDYuart".  However that uses the same system clock settings as the one that is faulting.

-Curtis

Hello Curtis,

OK got it. I did a prelim scan and the non-working program is using FPU. Is that right?

Regards

Amit

Yeah, it is.  Also the older program that worked didn't use the FPU.  Perhaps I need to enable Lazy stacking feature of the FPU.  I didn't think I was using any floats in any of my interrupts, but perhaps I should double check that I'm not somehow using a variable of type float in one of my interrupts.

What do you think?

- Curtis

Hey Amit,

Would you please explain the statement below?

"The error is shows that it is a IMPRE data bus fault"

What is IMPRE?  How did you look up what the fault was from the registers I provided?

Regards,

Curtis

So I figured out the second of my two questions about how to look up the fault code by looking in the data sheet.    Of course you can't blame me for not finding it immediately when it is 1401 pages long.  :p

Can you explain what it means by imprecise, besides that it is asynchronous?  Also, is the address in NVIC_FAULTADDR valid?  The description for the IMPRE bit on page 179 of the datasheet says "When this bit is set, a fault address is not written to the FAULTADDR register."

Also, here's another register reading that shows  the hard fault in this case was another that was escalated because it couldn't be handled.

Name: HFAULTSTAT   

Address: 0xE000ED2C

Value: 0x40000000

Regards,

Curtis

Hello Curtis,

An IMPRE Bus Fault typically gets asserted when the Data Bus gets corrupted due to a previous Fault

Regards

Amit