• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 1123 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

LM4F232 application does not trigger the SysTickIntHandler

Akshaya Mukund
Prodigy 100 points

I have shared the code for the problem I am facing can anyone please take a look at it and tell me where I am going wrong

/* Code snippet starts here */

SoundPlay()
{
    //
    // Mark both buffers as empty.
    //
    g_ulFlags = BUFFER_BOTTOM_EMPTY | BUFFER_TOP_EMPTY;

    //
    // Indicate that the application is about to start playing.
    //
    g_ulFlags |= BUFFER_PLAYING;
   
    //
    // Set the period which the SysTick will trigger the SysTickIntHandler().
    // For higher sampling frequencies, a more periodic interrupt is required.
    // Ex: /100  will suffice for 11.025kHz Fs
    //     /1000 will suffice for 44.100kHz Fs
    //
 SysTickPeriodSet(SysCtlClockGet()/1000);
    SysTickIntEnable();
    SysTickEnable();
   
    IntMasterEnable();
}

/* Code snippet ends here */

The problem I am facing is that after IntMasterEnable() I end up at the IntDefaultHandler as mentioned below. I searched and got to know that this is supposed to help me debug my issue but I don't know how.

/* Code Snippet starts here*/

IntDefaultHandler
        B       IntDefaultHandler

/* Code snippet ends here */

/* Code Snippet starts here*/

tBoolean
IntMasterEnable(void)
{
    //
    // Enable processor interrupts.
    //
    return(CPUcpsie());
}

CPUcpsie(void)
{
    //
    // Read PRIMASK and enable interrupts.
    //
    mrs     r0, PRIMASK;
    cpsie   i;
    bx      lr
}

/* Code snippet ends here */

Another point to note is that SysTickIntHandler() is not defined anywhere. Neither in the static libraries (that come with the firmware package) nor anywhere in my code. SysTickIntEnable() will enable the interrupt for SysTick while SysTickEnable() will just start the SysTick counter I presume. Is my program crashing since I don't have a SysTickIntHandler() or will this interrupt be handled by SysTickHandler().

FYI I am running this application via Keil MDK.

 

 

 

Any pointers to the above would be much appreciated.

Thanks in advance.

 

  • 0
    TI__Genius 15600 points

    What do you expect to happen when a SysTick interrupt occurs?  You must write your own SysTickIntHandler, it is not in the library.  Usually there is some operation that you want to occur as part of your application, when a systick occurs.

    Second, you need to put the interrupt handler function name in your interrupt vector table.  You are enabling the SysTick interrupt and it is firing, but there is no entry in the vector table for it, so you end up in the default handler.

    Take a look at the qs-logger app.  First, go look in qs-logger.c and search for SysTickIntHandler.  You will see that this is a function that was written for this application.  In this case it is simply incrementing a counter that is used for time-keeping in this application.  You will need to write your own SysTickIntHandler that does whatever you want to happen when a systick occurs.

    Then go look at startup_rvmdk.S for the qs-logger app.  The "_rvmdk" part means that it is for the Keil tools.  Scroll through the list of int handlers and you will see that there is an entry for SysTickIntHandler.  You need to modify your own startup code in the same way.

  • 0 in reply to Stellaris Joe
    Guru 117855 points

    @Stellaris Joe - Asked several fellow engineers/programmers to read your post - all agreed Excellent!  We liked your gentle direction of poster - and then a clear, systematic method to satisfy the program issues.  Your identification of - and then direction to - "qs-logger.c" really should "seal the deal" for this fortunate poster. 

    Congrats on job well done - please know that your efforts are recognized & appreciated.  Your broad-stroke solution is sure to assist many - I'd go so far as to promote this post to hallowed "top of page" (i.e. Sticky) entry - as the "care/handling" of ARM interrupts so often proves challenging for many...