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.

TM4C123 Systick maximum speed Issue

Hello, everyone.

I'm having a problem while trying to configure the Systick Interrupt. 

Currently my program generates an interrupt every 1 msec. All I do inside the interrupt routine is increasing a counter.

I'm also using the System ADC to register data from 3 different channels.  The ADC is triggered every 1 msec, using a Timer0 interrupt.

The Systick counter is used as a "Time-Stamp" for the registered variables.

 The problem is, now I'm trying to modify the code to sample at 2Khz, (i.e every 0,5 msec). In order to keep up with this change, I need to modify the Systick as well, to be triggered every 0,5 msec. 

This is the code for the Timers and Systick definitions. The sampling time is configured in the variable "SAMPLETIME".

void
InitializeTimers(void)
{	
    // Enable Timer peripherics.  
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER0);  // Timer 0, to trigger ADC conversions
    
    // Enable Processor Interrupts.
    ROM_IntMasterEnable();

    // Configure the periodic 32bits Timer
    ROM_TimerConfigure(TIMER0_BASE, TIMER_CFG_PERIODIC);
    ROM_TimerLoadSet(TIMER0_BASE, TIMER_A, SAMPLETIME);          //Triggered every 1msec 

    // Enable Timeout Interruptions for TIMER0A
    ROM_IntEnable(INT_TIMER0A);
    ROM_TimerIntEnable(TIMER0_BASE, TIMER_TIMA_TIMEOUT);

    // Configure - Enable Systick
    ROM_SysTickPeriodSet(40000);  // 1ms @ 40MHz
    ROM_SysTickIntEnable();
    ContadormsegSystick=0;
    ROM_SysTickEnable();  // Starts ticking
}

The System clock is set to 40Mhz 

ROM_SysCtlClockSet(SYSCTL_SYSDIV_5 | SYSCTL_USE_PLL | SYSCTL_XTAL_16MHZ | SYSCTL_OSC_MAIN);

When SAMPLETIME=40000, and     ROM_SysTickPeriodSet(40000);    ------ Everything works OK.

When SAMPLETIME=20000, and     ROM_SysTickPeriodSet(20000);    ------ All registered Systick's are 0. The system just doesn't work.

As far as I understand, Systick should work no matter the Clock Frequency. Is this OK?

Or am I perhaps having a problem in some other part of the code, which could be interfering?

(Just to mention, I'm also using the EEPROM, and UARTprintf commands, but I never change the system clock, or anything else. All I do is modify the SAMPLETIME value).

Thanks for taking the time to read this.

Regards, 

Martín.

  • Hello Martin,

    That is correct. The SysTick will work no matter what the system frequency is. However the value it counts depends on the clock source. The default setting is system clock. But when you want to change the value the first step must be to disable the SysTick using SysTickDisable API call.

    Secondly if it is the counter value in the SysTick Interrupt handler that is not getting modified, you need to ensure that the value is not being updated outside the handler.

    Regards
    Amit
  • Thanks Amit,
    I've checked this, but the value wasn't updated outside the handler.
    Regarding the SystickDisable, that was also a good hint. But I wasn't modyfing the value 'on-line'. Just changing it before compiling/downloading to the micro.

    I've just found the problem. It was other part of the code, as I suspected.
    After hours spent dealing with this.. I just had to post the problem here, to find the answer after 5 minutes....
    Well, what can one's do against Murphy's...
    Many thanks Amit, for your prompt response.
    Regards,

    Martín
  • Hello Martin,

    Enlighten us on the "other part of the code". Could be a useful resource on the forum

    Regards
    Amit
  • Might there be "one other" (somewhat important) consideration in the use of "Systick?"
    Systick is most always chosen due to its ease & convenience.

    As Amit long has warned - Systick does not enjoy the accuracy you may seek as it may be "delayed" (but not advanced) by other, higher priority program functions and/or interrupts. Thus - your use of Systick as a "time stamp" surely reduces that stamp's accuracy.

    Again - as Amit has stated - any one of the ARM's many timers will (most always) outperform Systick - thus may warrant your consideration...

  • Martin Cunningham said:

    Currently my program generates an interrupt every 1 msec. All I do inside the interrupt routine is increasing a counter.

    I'm also using the System ADC to register data from 3 different channels.  The ADC is triggered every 1 msec, using a Timer0 interrupt.

    The Systick counter is used as a "Time-Stamp" for the registered variables.

    You may want to re-visit that program design, You gain no advantage by using two clocks in the way you have and indeed may run into timing inaccuracies because of it. First question to ask, is why are you using systick to count the number of time periods when you have an A/D clock running at the same frequency?

    Depending on what you are trying to achieve, there are other techniques with higher precision and accuracy.

    Robert

  • Hello Robert, cb1, Amit.

      Thanks once again for your constructive responses. 

    The use of Systick was just my first option. After reading cb1's reply, I decided to replace it with a more-accurate Timer. 

    The need for two timers arises because I need to register data, which can be obtained at different sample rates. I.e, my ADC's timing clock gets modified during the program execution, according to the user selections. 

    My Tiva is linked to a software, which plots the required graphs on screen. Thus the need of a fixed-value timing. The quickest way for me to perform debugging is just runing the program, and watch the different plots. 

    The "other parts of the code" I referred to, Amit, are the ones were I perform some calculations prior to sending the acquired data. My mistake was really a silly one:

    When I first tried to modify the Systick, I didn't set the System clock speed correctly (it was set to 20Mhz, so according to the values loaded to the Systick and ADC timers, 0.5msec was impossible to achieve), so the graph wasn't plotted at all.

    Then, when I finally corrected this, I forgot I had commented out the line wich sent the time-stamp data.  

    I don't know if there is some constructive-learning to be obtained from this, except from the fact that we should always pay attention to the System clock definition..

    Now, the Systick vs Timer issue, is a different story. If there´s a way to perform this double registration (on one hand, the Time Stamps, and on the other, the data obtained at different sample rates), I most surely would like to know.

    Again, thanks for all the support. 

    Kind Regards,

    Martín

  • Martin Cunningham said:

    The need for two timers arises because I need to register data, which can be obtained at different sample rates. I.e, my ADC's timing clock gets modified during the program execution, according to the user selections. 

    Pardon - you surely "know what you mean" yet I don't believe, "the need for 2 timers" has been successfully conveyed - in your writing.

    A timer triggers the ADC and that action (likely):

    a) logs the time of that trigger into your, "time stamp"

    b) further logs the result of that ADC conversion

    Cannot that be achieved via a single timer?   Even - and especially if - that timer must be adjusted to provide your specified, "different sample rates!"

    One method (not the only one) is to simply "count & record" the number of such timer-triggered, ADC conversions.   This may work as you (likely) "know" the sample rate - and when and/or if - that sample rate has changed.   The time from your initial, "Start of trigger" would then be: "number of captured/stored timer-triggers * timer-trigger period."   Note: you must "mark" the "timer-trigger period" in use during each sample rate - which does (somewhat) complicate...

    Now a second timer (or even the 2nd half of a single timer) may serve to monitor the "accumulated time from Go!"   It's "live value" then would be logged along w/the ADC data which is separately timer-triggered.    This may prove simpler/faster - in the long run.

    Use of the MCU's "Wide Timer" seems far preferable as your, "time-stamp" vehicle.   (as this greatly reduces the occurrence of timer, "roll-over" - which you MUST manage.)

    The simpler, standard timer should easily serve as your (far shorter duration) "ADC trigger."

    As always - KISS dictates that you implement one aspect of your program at a time.   "All at once" most never works (correctly) - and confounds troubleshooting...

  • Martin Cunningham said:
    My Tiva is linked to a software, which plots the required graphs on screen. Thus the need of a fixed-value timing.

    For fixed value time there is no need to record time stamps, just what the interval is.  You only need time stamps if the time for each sample varies in a non-easily predicted fashion.

    In the latter case, my first option would be cb1's mention of a 64bit timer.  Let it free-run and just read the value. As he mentioned you do need to manage overflow but your graphing SW may be sufficiently capable of handling it.

    Robert

  • Hello cb1-, Robert
    Thanks for, once again, providing good advice. I realize now two things.
    a) I actually don't need an additional timer.
    b) I definitely didn't convey my system's *intended* behaviour properly in my previous post.

    The sample rate isn't modified 'online'. The program is intended to work performing different "runs", triggered by the user.
    The sample-time modifications occur in-between this runs, but NOT during the ADC's conversions.
    So, for example, I can make a run at 1Khz Sample Rate (trigger every 1 msec), then ONLY after finishing it and sending the obtained data to the PC, I can modify the SR for a different run.

    So, as you've clearly pointed out, I don't need the additional timer. I can just generate an array of Time Stamps knowing the Sample Rate (i.e, the interval with which the samples are taken).
    I don't know why I kept on insisting with the use of a 2nd timer, it was a misconception dragged from the very beggining of the project.
    I'm gonna try this modification, and let you know.
    Thanks for all the feedback!
    Kind Regards,

    Martín
  • Thank you, Sir. While the "Shamrock Shake" has departed - not so the, "flow of green" gratefully received by posters Rob't & cb1...
    Your recognition that, "early on" - and likely w/out full/necessary MCU awareness - you, "Locked course" points to your great, "coachability & openness to "rethink!" Usually - just as in sailing - that ability to "shift course w/the wind/tech issues" bodes well for a successful sail/tech project... Bon chance mon ami...