• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 1685 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.

SysTick

Elad Rind
Intellectual 370 points

A quick question,

I am using systick in order to have some sort of a timer in my system. However, I would also like to save data to a file every X number of ticks. My question is, assuming the time it takes to save data to the file is shorter than the tick time would my time counter still be accurate if my code was something like this:

void
SysTickHandler(void)
{

static uint32_t last_save_time=0;

    // Increment the tick count.
    g_ui32TickCount++;

if (g_ui32TickCount-last_save_time>=100)

        {
            last_save_time=g_ui32TickCount;
            WriteFile1();
        }
}

Thanks in advance.

  • 0
    TI__Mastermind 26900 points

    While this should work, theoretically, it sets of my "don't do this!" warning because it could mess up the interrupt latency in the system. By default, SysTick has a higher priority than any peripheral interrupt so you would need to make sure that you configured it lower so that your long file operation wouldn't hold off all other critical interrupts.

    An alternative, assuming that the actual file write time isn't critical, is to merely set a flag in the SysTickHandler and look for this in your main loop. When the flag is set, clear it and perform the file write in the main loop. As long as your main loop executes at least once per SysTick interval, this will work and not affect your interrupt latency.

  • 0 in reply to Dave Wilson
    Guru 117855 points

    Mid Friday Greetings, Sir:

    Thanks once again for a valued, well detailed post describing possible pitfalls and, "safe harbor" use/navigation.

    Our group - w/in past month - ran afoul of just that, "too high SysTick priority" you've just described.  Seemed "harmless enough" to raise SysTick's priority at the time - and all appeared "well" for first minute or so - and then our PWM Generator interrupt became stalled. 

    We did not make the immediate connection to SysTick's increased priority - saved ourselves by "rolling back" to last, "known good" code - and determined SysTick's "promotion" to be the cause.  So - our group serves as "real world" confirmation of your sound, instructive advice.

    One SysTick define (outside of your post) does continue to disturb:

    #define FAULT_SYSTICK           15          // System Tick   *** this found w/in file, hw_ints.h - used as illustrated below:

         ROM_IntPrioritySet(FAULT_SYSTICK,   0xC0);

    The use of "FAULT" here - in the define of SysTick's priority vector - seems ill chosen .   "FAULT_SYSTICK" is included w/in hw_int's.h listing of "fault assignments."  SysTick normally operates w/out "fault" - thus the use of "Fault" w/in its definition - raises concern.  In fact - our group spent several hours searching for a more appropriately named alternative - without success.  And - likely we were not alone...

    Indeed that define does work - (we realize that SysTick's vector number is 15 (as define shows) - it is the questionable, "fault" designation which causes distress.

    And - in the quest for a real & best answer - propose ARMv7M Arch. Ref. Manual: (a true copy, below:)

    B1.5.2 Exception number definition

    Table B1-4 Exception numbers:

    Exception #  Exception
    1                    Reset
    2                    NMI        *** not usually a fault
    3                    Hard Fault
    4                   Mem Manage Fault
    5                   Bus Fault
    6                  Usage Fault
    7-10            Reserved
    11               SVCall      *** not a Fault
    12               Debug Monitor (classified as Fault)
    13               Reserved
    14               PendSV   *** not a Fault
    15               SysTick    *** not a Fault
    16               External interrupt 0

    Yet - hw_ints.h deviates from this ARM supplied directive - listing everything herein as a Fault!  (minus Reset & External interrupt 0)   ( i.e. hw_ints.h  // The following are defines for the fault assignments (then come # 2-15)

    And - as theorized above - and now confirmed via ARM Source - hw.ints.h define of SysTick, SVCall, NMI & PendSV vector numbers as an "Error" is not as prescribed by the source ARM document - appears instead an invention by hw_ints.h developer.  Appears that only 5 of those listed qualify as "Fault" - yet all are so judged & classed by hw_ints.h - which is indeed incorrect and causes confusion...  (Yes - the defines do work - but words do have meaning...)

    Of course you neither made nor contributed to this improper classification.   As this SysTick subject landed earlier today - seems reasonable now to raise this "suspect" SysTick define wording issue - and formally request review & relief.     (hopefully saves multiple others from waste of time/effort - caused by, less than "stellar" word choice...)

    Thanks again for all you do - and have done - both here & w/in earlier forum...