delay_cycles

pocho said:

I have this delay_cycles (100000) clocked at 1us suppose that uses 100ms instead it takes 33ms, there is something that happens in assembly.

If the the compiler handled the intrinsic correctly, the assembly code probably looks like this:

       jmp     here
here:  mov     #33331,r15
loop:  add     #-1,r15
       jc      loop

My question is, is each cycle is 1 usec?

Which compiler are you using? Can you post the generated assembly code here?

    -- Anders Lindgren, IAR Systems, Author of the IAR compiler for MSP430

Hello old_cow_yellow: I hope that each cycles is 1us, I have set as:   BCSCTL1 = CALBC1_1MHZ;                      DCOCTL = CALDCO_1MHZ;  // Set DCO to 1MHz

I don't understand if delay_cycle, refer at DCO.

Hello Anders:

I don't know the compiler, where i can read it? However, I use Code composer with ez430rf2500.

Now i cannot post the assembly code, because the msp is in the university, thursday i can  post ! Thank you and see you

pocho said:

Now i cannot post the assembly code, because the msp is in the university, thursday i can  post !

You don't need the physical MSP device to get the assembly code. Turn on the option for the compiler to output the generated assembly files (with C code as comments) and recompile. Not sure where this option is in CCS as I use IAR tools.

Also, there should be a Help->About box that will give you the CCS version and compiler version (2 separate version identifiers).

This is what IAR generates for the MSP430F2274 device:

//    4 int main( void )
main:
          CFI Block cfiBlock0 Using cfiCommon0
          CFI Function main
//    5 {
//    6   // Stop watchdog timer to prevent time out reset
//    7   WDTCTL = WDTPW + WDTHOLD;
        MOV.W   #0x5a80, &0x120
//    8   
//    9   BCSCTL1 = CALBC1_1MHZ;
        MOV.B   &0x10ff, &0x57
//   10   DCOCTL = CALDCO_1MHZ;  // Set DCO to 1MHz
        MOV.B   &0x10fe, &0x56
//   11   
//   12   __delay_cycles(100000);
        ////////////// Start of 100000 cycles delay.
        JMP     ??main_1
??main_1:
        MOV.W   #0x8233, R15
??main_0:
        ADD.W   #0xffff, R15
        JC      ??main_0
        ////////////// End of delay code.
//   13 
//   14   return 0;
        MOV.W   #0x0, R12
        RET

0x8233 = 33,331

Remember that each instruction is not 1 cycle in execution. That is why the number is 33,331 and not 100,000.

Are you sure that your clock is stable at 1MHz? Have you tried sending the clock to the MCLK pin and measuring the frequency to make sure it is correct? I am not familiar with the 2xx family, but other like 5xx require to clear fault flags before the clock is stable.

__delay_cycles() usually works exact. The code takes exactly the given number of MCLK cycles to execute. It is highly unlikely that you hit a bug here,a sit is a rather simple implementation and nobody noticed a problem here before.
However, how much time it takes to execute the code depends on several factors:

- The MCLK speed. A clock cycle is a clock cycle. On 1MHZ MCLK it is 1µs, but on 3MHz, it is only 330ns.
- the code may be interrupted by interrupts. Execution time of the interrupts adds to the delay.
- on FR devices with higher clock speeds, the FRAM access adds waitstates. This also may slow down the code execution and extend the delay.

Since your code executes faster than expected, you are likely not running with 1MHz, but faster. And interrupts may slow it down again a bit, resulting in the observed 33ms.