LED blinking on TM4C123 fails if not "halting clock cycles"-CodePudding

I'm learning Embedded System by following this tutorial. In their attached code for LED blinking on TM4C123, they created the variable ulLoop which made me confused, since they just asigned the click enabling byte to ulLoop but never used it afterwards. However, I tried deleting the line writing ulLoop = SYSCTL_RCGCGPIO_R; and the LED stop blinking, as they said in the tutorial "The uloop variable and the statement containing uloop is present there only to halt 3 clock cycles before moving to peripherals, which is a must while working with TIVA."

I cannot understand what did they mean by "halt 3 clock cycles" and "moving to peripherals", and why it needs to halt 3 clock cycles, not 4, or 5 cycles, or not at all. In addition, if I know nothing about what's mentioned in the tutorial regarding the magic variable, just finding out the program not working, how am I supposed to know where the problem is without further information, since during building there is 0 errors and warnings. Pealse pardon with me if the question is not asked in a right way or sounds silly.

#define SYSCTL_RCGCGPIO_R (*(( volatile unsigned long *)0x400FE608 ) )
#define GPIO_PORTF_DATA_R (*(( volatile unsigned long *)0x40025038 ) ) 
#define GPIO_PORTF_DIR_R  (*(( volatile unsigned long *)0x40025400 ) ) 
#define GPIO_PORTF_DEN_R  (*(( volatile unsigned long *)0x4002551C ) )

#define GPIO_PORTF_CLK_EN  0x20
#define GPIO_PORTF_PIN1_EN 0x02
#define LED_ON1        0x02
#define GPIO_PORTF_PIN2_EN 0x04
#define LED_ON2        0x04
#define GPIO_PORTF_PIN3_EN 0x08
#define LED_ON3        0x08

#define DELAY_VALUE   1000000
volatile unsigned long j=0; 
static void Delay(void){
    for (j=0; j<DELAY_VALUE ; j  );
}


int main ( void )
{
volatile unsigned long ulLoop ;          // I don't understand why creating this variable
SYSCTL_RCGCGPIO_R |= GPIO_PORTF_CLK_EN ;
ulLoop = SYSCTL_RCGCGPIO_R;              // But if not adding this line the LED won't blink
GPIO_PORTF_DIR_R |= GPIO_PORTF_PIN1_EN ;
GPIO_PORTF_DEN_R |= GPIO_PORTF_PIN1_EN ;    
GPIO_PORTF_DIR_R |= GPIO_PORTF_PIN2_EN ;
GPIO_PORTF_DEN_R |= GPIO_PORTF_PIN2_EN ;
GPIO_PORTF_DIR_R |= GPIO_PORTF_PIN3_EN ;
GPIO_PORTF_DEN_R |= GPIO_PORTF_PIN3_EN ;
        
// Loop forever . 
        while (1) 
        {  
            GPIO_PORTF_DATA_R &= LED_ON3;
            GPIO_PORTF_DATA_R &= LED_ON2;
            GPIO_PORTF_DATA_R |= LED_ON1;
            Delay();
            GPIO_PORTF_DATA_R &= LED_ON1;
            GPIO_PORTF_DATA_R &= LED_ON2;
            GPIO_PORTF_DATA_R |= LED_ON3;   
            Delay();
            GPIO_PORTF_DATA_R &= LED_ON3;
            GPIO_PORTF_DATA_R &= LED_ON1;
            GPIO_PORTF_DATA_R |= LED_ON2;
            Delay();
                
        }
}

CodePudding user response：

Since in this the previous line

SYSCTL_RCGCGPIO_R |= GPIO_PORTF_CLK_EN ;

The program is enabling the clock, this line

ulLoop = SYSCTL_RCGCGPIO_R;

is just a dummy code that gives a little bit of time to the microcontroller clock to stabilize.

You will find this valid for any microcontroller you will be working with, that after clock setting you must allow some time for the clock to stabilize.

Now, Why 3 clock cycles? This info you should find when reading the microcontroller datasheet in which it shall be specified how many clock cycles are needed to stabilize the clock?

Why not 5 or more? Of course, you don't want to waste so many clock cycles in this operation, so the rest of the program can be executed as soon as possible.

How does this dummy line correspond to 3 clock cycles?

ulLoop = SYSCTL_RCGCGPIO_R;

Well, this is really different from one controller to another or more specifically from compiler to the other. The compiler does translate this c-code line into assembly code. each assembly line takes one clock cycle for execution. So it seems like whoever wrote this code, just looked out at the generated assembly code from the compiler and finds out this line is translated to 3 assembly instructions.

how am I supposed to know where the problem is without further information

In the embedded system world, this can be achieved by debugging. Some of the issues are really hard to debug especially when it's something in the controller initialization sequence. You should be very careful when initializing the controller (clock, peripherals) by following the datasheet instructions/recommendations.