Interrupt Enable freezing Debug

May I suggest several major simplifications - with the goal being that you can at least program the MCU - and then run your code? 

Our group subscribes completely to KISS (simplicity) - my sense is that you have too much going on - and that it is way too soon - and overchallenges your learning process.   If you accept/buy into this - here's how I'd proceed:

a) avoid interrupts for this early stage

b) avoid use of Sleep or Deep Sleep

c) avoid use of any/all pins which default into special modes (believe that PF0 is NMI as default - requires special unlock procedure)

Of course you want each/every one of these - but experience teaches that small, gradual, less complex steps - are the fastest, easiest, safest means to success.

This said - can you find an existing switch on your board - that is not belabored w/special "unlock" requirements.  (that's too much - too soon - too distracting)  Then - find one or several leds which attach to GPIO.  Suggest then that you write basic code to read a single switch - NO Interrupts - and while that switch is "active" - turn on the Led.  (when switch releases - turn the Led off)

Once this code runs in debug mode - follow your IDE's guidelines to program this code - at the proper location - into your MCU.  Now remove power - then restore power - and see if the MCU has successfully retained your program code.  This method best insures that your IDE, MCU board and key components, and your methods are reasonably proper.  Only after this basic procedure can be reliably repeated - would I venture forward to your earlier expressed goals - and then I'd attack only one of those at a time.

Big fan of KISS myself just wanted to really play with my new toy haha.

a. I have interrupts working in other parts of my code it's just this section that seems to be giving me real trouble and I could not figure out why.

b. I noticed that sleep was a bit more complex than I originally thought hence why it was commented out for now and I will hopefully go back to later.

c. You are correct about PF0 but I didn't find the commands that complex I mean it takes a lot to find exactly what needs to be done but once everything is found it's not hard to complete.

Also I can retain the program before I introduce this interrupt, I have some PWM's running on the chip (GPIO_PORTB so no issue there) and if I comment out everything pertaining to this interrupt my PWM's maintain the proper values which I checked using a multimeter. Honestly the reason I was experimenting with the interrupt was because it was my next goal and seeing as how I had everything else working as I wanted it to I found this to be the next logical step. Now yes PF0 was a bad switch to  chose but I only have 2 on this board and I wanted to have 4 different states not just 2 to really be certain that the interrupt was working correctly. 

In 10+ years working w/ARM MCUs - from many makers - never once have we found an interrupt to cause the "failure to program" issue you describe.

Only thing else I can suggest is to "strap" the switch pin to another GPIO Port pin (via a jumper at your board's edge connector) and reconfigure the troublesome interrupt to another port. 

Using a multimeter to confirm PWM output is resourceful - but not too "normal/customary."   (unless you've added a proper R-C network - suitable for that PWM's frequency and your desired "speed of response."

Just returned to your code (scene of the crime) and note:

if(tmp==0x00){ //Both buttons pressed

yet few lines down - code states that 0x01 results from one switch press and 0x10 results from the other switch press!

Both cannot be true!  (usual for switch to drive the MCU pin to 0)

Yeah I was worried that would be the issue. In that case I'm guessing I made a mistake will just have to hack away at it a bit more. 

I may take your idea and just use the one switch which doesn't have awkward configuring see how that goes.

The reasoning for the multimeter is a kind of "good enough" test. Most of my electrical equipment is at school while I'm home for Spring break leaving me with the more "resourceful" solutions to issues. To my knowledge a multimeter uses an averaging system which means that the change in duty cycle would represent a change in detected voltage, as far as I can tell it's working.Now with an oscilliscope I could get a more accurate measure or with a DC motor I could see a change in speed but like I said no real equipment with me right now.

Our posts just crossed - take a new look @ the bottom of my last post.  (appears you've a code conflict)

Re: "No real equipment right now."  Vastly untrue - that little MCU is more than capable of far outperfoming most any multi-meter - and can easily tell you both the frequency and PWM duty cycle.   You'd have to write some new code - and route the PWM Generator's output to a GPIO input (Timer - likely suspect).

Have to plead "temporary insanity" re: switch code analysis.  It is quite possible that code is correct - and that each switch closes to ground.  (your comments could better describe/relate pin ID # - (i.e. SW1 provides no insight as to "where on the port" that sw is attached) preventing "quick read" errors - as I've just done...)

I read your message and I don't understand how this is an issue. Through the nature of these switches being on my board I configured them using the following command.

GPIOPadConfigSet(GPIO_PORTF_BASE, GPIO_PIN_0|GPIO_PIN_4, GPIO_STRENGTH_2MA,GPIO_PIN_TYPE_STD_WPU);

Which makes them falling edge thus a button press as you said makes a 0 be returned. I don't understand why my Boolean statement can not be true. I'm using the GPIOPinRead command which as far as I can tell returns a bit packed byte of every pin on that port but only reads from the ones requested defaulting everything else to 0. When I do enable the interrupt in my code it runs perfectly fine the button presses go to the proper case, which now that I'm looking into it should probably be a switch statement, but as I said it does run perfectly fine up to this point. My interrupt works, but the program does not continue, for example the PWM definitions are latter in the code and when the interrupts are enabled my multimeter shows that the PWM pins are no longer being set meaning the program froze immediately after enabling the GPIO interrupt. 

Kindly look again @ my 16:58 post - my pleading there re: switch code and its comments.  (i.e. SW1 inadequately relates to PF0 - imho) 

I have suggested a method to move this troublesome interrupt to another port - see if issue persists -  I'm out of tricks beyond that.  Good luck.

You did not post all your code. The behavior you are observing can be caused by uninitialized peripheral. Please check your code for small typographic errors.

Set optimization to off in your project properties for easy debug. Create breakpoint inside fault ISR.

The absurd of e2e is you cannot post code on this forums...

@Maciej:  All good points - poster should appreciate.

We've found that copying code from IDE into "Notebook" - and then pasting to forum - enables single-spaced import. 

OP's issue description really not precise - difficult to diagnose when facts few & uncertain...