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.

CCS/TM4C123GH6PM: how to use systick to create delay.

Part Number: TM4C123GH6PM

Tool/software: Code Composer Studio

I tried to use systick to create a delay.But only first led is always on ...

my code is below..

#include <stdint.h>
#include "tm4c123gh6pm.h"
void SysTick_Init(void); // initialize SysTick Timer
void SysTick_Wait(unsigned long delay1);
void SysTick_Wait10ms(unsigned long delay1); // waiting time

// ***** 2. Global Declarations Section *****
// FUNCTION PROTOTYPES: Each subroutine defined


//Next[8] array represents 8 inputs and the next state transition
//The first array element represents 000 input, the second represents 001 input and so on upto 111 (eighth input)
//Input bits representation- MSB=Walk Sensor,Middle bit=South Sensor and LSB=West Sensor
//FSM[9]={
//{ouput to Six signal LEDs (TrafficLights_Cars),output to two Pedestrian LEDs (TrafficLights_Ped),Time in 10ms units,Next[8] array elements(next states)},
// ..............

unsigned long Input;
// ***** 3. Subroutines Section *****

int main(void) {
volatile unsigned long delay;

GPIO_PORTB_AMSEL_R=0x00; //disable analog on port B
GPIO_PORTE_AMSEL_R=0x00; //disable analog on port E
GPIO_PORTB_PCTL_R=0x00000000; //enable regular GPIO
GPIO_PORTE_PCTL_R=0x00000000; //enable regular GPIO
GPIO_PORTB_DIR_R=0x1F; //outputs on PB0-5
GPIO_PORTE_DIR_R=0x00; //inputs on PE0-2
GPIO_PORTB_AFSEL_R=0x00; //disable alternate function
GPIO_PORTE_AFSEL_R=0x00; //disable alternate function
GPIO_PORTB_DEN_R=0x1F; //enable digital I/O on PB0-5
GPIO_PORTE_DEN_R=0x07; //enable digital I/O on PE0-2
while(1){
GPIO_PORTB_DATA_R=0x01;
SysTick_Wait10ms(100);
GPIO_PORTB_DATA_R=0x02;
SysTick_Wait10ms(100);

}

}
void SysTick_Init(void){
NVIC_ST_CTRL_R = 0; // disable SysTick during setup
NVIC_ST_CTRL_R = 0x00000005; // enable SysTick with core clock
}
// The delay parameter is in units of the 80 MHz core clock. (12.5 ns)
void SysTick_Wait(unsigned long delay2){
NVIC_ST_RELOAD_R = delay2-1; // number of counts to wait
NVIC_ST_CURRENT_R = 0; // any value written to CURRENT clears
while((NVIC_ST_CTRL_R&0x00010000)==0){ // wait for count flag
}
}
// 800000*12.5ns equals 10ms
void SysTick_Wait10ms(unsigned long delay1){
unsigned long i;
for(i=0; i<delay1; i++){
SysTick_Wait(800000); // wait 10ms
}
}

  • Hi,
    You are setting the PB0 to 1 only.
    GPIO_PORTB_DATA_R=0x01;
  • Won't poster experience a far larger - and more critical "delay" - due to the unwise (and un-alerted) use of Direct Register coding?

  • Greetings Charles!

    cb1 is full of reason here! You should be almost forbidden to support posts with such unnecessary and complex DR writing. Let's avoid the evil before it hatches! :)

    Sudheer,

    PLEASE use TivaWare. Read some posts or look at some examples, it will take you a couple of hours to understand what it is about, and after that ALL your coding will be easier and faster.
    Kindly when posting code, paste using the </> icon on the Rich Formatting option, so that it can be easily read.
    And, although the use of SysTick is not really a problem, you won't be able to do anything else with your expensive 32bit MCU if you code your blinking like that... Study interrupts and timers, and use those for your goal.

    If these guidelines are followed, nice and supporting gentlemen like Charles will be able to help much more people on a regular day shift - or use the extra time to product more examples and guidance papers!

    Regards

    Bruno
  • Hi Bruno,

      I know some educational institutions require their students to learn how to program the MCU using direct register access. I think the instructors have their intentions to do so. I don't want to debate here. Of course, from support point of view it would be easier if the TivaWare library are used. Thanks.

  • Hi Charles,
    I fully understand your consideration - had not thought of that.
    Of course this is a TI's policy decision, I have no say in it - but my point of view is that this should be really an E2E forum - where the E stands for Engineer, not for Estudante... Of course we are all willing to help, but if it gets flooded with basic educational-institution level questions, the overall quality of the platform decays. Hence, if the institution itself require direct register (which DOES make sense so that students still understand what is going on "inside" the MCU's), these very institutions should be the one to back up their students and clear their doubts.
    Cheers
    Bruno
  • I found the answer, remove this line NVIC_ST_CURRENT_R = 0; to create delay .
  • Some here may have noted the similarity between, "Vendor forum guides" and parents.    (both charged w/guiding, encouraging and (some) discipline...)

    Following illustrates the "weakness" evident here (this thread):

    Male Parent: "I forbid you to do that!"  (said to kid)

    Female Parent: "Yes - you can do that!"  (said to same kid)

    Consistency has (long) been proven to "work best."    And has not flowed thru to this thread...

    As small, tech biz owner - firm/I would not last long if we followed the (likely) job-security practices of those preaching (primarily) the use of, "Direct Register or ASM" during project/product development.   The "Race is to the Swift" - is it not?   One must study economics as well as engineering - highest profit accrues to those who ARRIVE EARLY to market.   DRM proponents insure (very) LATE arrival to the market-place - can that be good?

    Is it not MORE IMPORTANT for students & those "in the field" to seek, "Best Practice - Techniques & Methods?"   This vendor provides a superb API - which is, "TRIED, TESTED, PROVEN!"   Can it be wise to reject that?    Really?

    Note too - "Each/Every use of DRM or ASM" is (most always) a New Adventure!   And the code resulting is (always) "UNTried, UNTested, and FAR from Proven!"   Proof of this arrives daily - right here - as DRM users "Crash/Burn" w/obscene regularity.    Really - other than developing in "SLOW & ERROR INVITING MOTION" - What has been learned?

    Use of the API "In no way" precludes a full review of the applicable Registers.     To my mind - rejecting the API is an unwelcome vestige of the past - when (only) Unguided Register Manipulation was available.    

    Today's tech development is Global in Nature - and rejecting, "Clever, Focused, Tested & Extensive" best practice ENHANCEMENTS (i.e. Vendor's API) is NOT justifiable!