FaultISR when using RGBIntensitySet with LM4F120

I'm not familiar with the lab, but I think the issue with setting the intensity is that it uses floating point and you're not enabling the FPU.  Add these lines to the start of your code:

    FPUEnable();
    FPUStackingEnable();

My guess is that the problem with the button polling, is that you're passing a pointer to 2 different variables for the *puiRawState parameter.  This'll effectively reset the raw state each time and confuse the debouncing code in the button driver.  You only need one variable and one call to ButtonsPoll since each button's state is later masked by the BUTTON_PRESSED macro.

Thank you for you answer!

You were right about the Button part. I changed to code so that the other button changes the LED colour in the oposite order of the other button and it work fine :)

The RGBIntensity part does not work though. I added the two lines of code just after start of main but i still get stuck in the FaultISR loop. When i add the FPU lines i get warning messages from the compiler: 

"Description Resource Path Location Type
<a href="file:/C:/ti/ccsv5/tools/compiler/dmed/HTML/225.html">#225-D</a> function declared implicitly main.c /ButtonsTest line 10 C/C++ Problem"

I look up the FPU code functions in the manuals and added #define "drviverlib/fpu.h" i also imported the fpu.h and fpu.c files to my project. Perahs this is wrong, but i tried everything i could think of. Nothing seems to help and I still get stuck in the FaultISR loop.

Here is my code with slight midifications:

#include "inc/hw_types.h"
#include "inc/hw_memmap.h"
#include "driverlib/sysctl.h"
#include "driverlib/gpio.h"
#include "drivers/buttons.h"
#include "drivers/rgb.h"
#include "driverlib/fpu.h"

int main(void)
{
FPUEnable();
FPUStackingEnable();
unsigned char ucStateR;
unsigned char ucDeltaR;
//unsigned char ucStateL;
//unsigned char ucDeltaL;
float intensity = 0.5;
int LED = 2;
int tal = 0;
SysCtlClockSet(SYSCTL_SYSDIV_4|SYSCTL_USE_PLL|SYSCTL_XTAL_16MHZ|SYSCTL_OSC_MAIN);
SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);
GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3);

ButtonsInit();

while(1)
{
tal++;
SysCtlDelay(10000);
ucStateR = ButtonsPoll(&ucDeltaR,0);
//ucStateL = ButtonsPoll(&ucDeltaL,0);

if(BUTTON_PRESSED(LEFT_BUTTON, ucStateR, ucDeltaR))
{
/*intensity = intensity + 0.25;
if(intensity>1.25)
{
intensity = 0;
}*/

RGBIntensitySet(intensity);
LED = LED/2;
if (LED == 1) {LED = 8;}
GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3, LED);
SysCtlDelay(2000000);

}

if(BUTTON_PRESSED(RIGHT_BUTTON, ucStateR, ucDeltaR))
{
RGBIntensitySet(intensity);
LED=LED*2;
if (LED == 16) {LED = 2;}
GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3, LED);
SysCtlDelay(2000000);

}
}
}

Have you tried debugging the fault to determine what caused it? If not, there's a really useful application note here that describes how to go about this.

Okey so i looked up the NVIC_FAULT_ADDR value in the datasheet and it sais that it is Cortex-M4F Peripherals (Sys Tick, NVIC, MPU, FPU and SCB). I do not know what this means. 

I also tried the other method sugested in the docment you linked. This was to lok at the MSP Register and the at the stack pointer the could be found by looking at the MSP register value in he memory browser. When doing this the SP was all zeros 00000000 so the code didn't even run? I wasn't really sure how to interpret that when look in the disassembly browser, but looking at what in the R0 register it seems like it was some problem with timer 0. So i enabled timer 0 but that did not help. I  so lost in this!

If you are going to be working on ARM devices, I really recommend that you make a point of learning about how the processor works and, specifically, how the registers are used. This will be vital to debugging problems in the future. I guarantee that you will see many, many faults (I deal with them pretty much every day) so understanding how to debug them is absolutely critical.

In this case, you don't need to worry about MSP. Register R13 holds the stack pointer and the bottom 8 words on the stack (the stack grows downward and the stack pointer points to the bottom, full location in the current stack) contain state information about what the processor was doing when the fault occurred. Most of the time, this is enough to tell you where the program was executing and often there are enough other hints there that you can find the cause very quickly.

In your particular case, you want to look in the drivers/rgb.h file and take a look at the API for the LED. I'm sure you'll find that you have forgotten to initialize the module and, as a result, your call to RGBIntensitySet() is trying to access peripherals that you have not yet enabled. When you try to access a disabled peripheral, the processor throws a fault.