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.

ButtonsInit() causes FaultISR

Hi, I've spend most of the day figuring out how to properly use the buttons on my LM4F. I've read it is recommended to use the included API for button polling and so I did, but because of the complexity of the included example qs-rgb I looked up on the internet and found a blog explaining how to use it. Problem is that whatever I do ButtonsInit() crashes.

http://unboxnbeyond.wordpress.com/2013/04/14/using-button-h-for-inbuilt-buttons/

Could someone have a look and see what's wrong with it?

I've noticed a lot of inexperienced users of this microcontroller are having a problem with this "simple" thing and are instead trying workarounds (e.g. http://codeandlife.com/2012/10/16/ti-stellaris-launchpad-test-run/ ) that are not always perfect.

I'm including the FaultISR() code that shows up when I run the example code from the first link.

  • Hi,

    Your program crashes at startup_ccs.c line 255 which is the NMI interrupt - it means the pin PF0 which is by default NMI is not changed to normal GPIO pin - this is done in ButtonsInit() - if you added the file buttons.c to the project and the #include "buttons.h" to the main file and still crash, then go into this function step by step and determine the exact line which determines the crash. 

    Second, keep in mind the buttons are mechanical ones and to be read correctly you need to use the debounce function ButtonsPoll - preferably into a timer interrupt, so you have some small work to do until succeed. The author of your first link makes the correct settings, the second link use inappropriate GPIO reading function, without function ButtonsPoll.  

    Petrei

  • Thank you Petrei.

    While doing what you suggested - going step by step to find the fault I got an error message "Can't find a source file at "C:/DriverLib/build/DriverLib.test/driverlib/sysctl.c" "

    I was using Step Into and that happened on just the second button press.

    But I figured that can't be right and I opened a new project in CCS, linked all the files again and pasted the code. To my surprise this time it worked - as in no error messages and the program runs as intended. It boggles my head how CCS behaves sometimes. I probably shouldn't have used an imported Lab code and modified it so much, but I rely heavily on these examples...

    Let's now hope the functions will work in my piece of code where I use UARTs.

  • Might there be an elephant in this room?   And if so - beast may warrant some consideration...

    Those seeking to flee/avoid/run from complexity - likely should not be "learning" w/an LX4F!  (or M4 - or M3 - or M0) from any vendor...

    These are natually, highly complex MCUs (esteemed firm Olimex - long past advised, "Not for early/first use!") 

    Discount "eval" price lures use - and then the struggle to, "unwind" the complexity...

    The fact that, "a lot of inexperienced users" made this choice may comment more heavily upon those users' awareness/plan/search efforts - than upon the adequacy of the supporting code provided by this MCU vendor.  (which - all things considered - is quite excellent)

    The other responding poster highlights the fact that most code does not operate w/in a, "vacuum" - just like in serious schools - there are often, "prerequisites!"  And - the more complex the MCU - the more those "added bits/pieces" intrude.

    Simpler MCUs abound - employ data manuals less than 1300+ pages - and may - more predictably - reduce complexity...  They may offer a superior path to learning...  Price alone decisions do not too often deliver optimal - overall solutions...