• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 79 subscribers
  • Views 1468 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP430FR5969: Instruction cycle execution question

Edwin Maynard
Prodigy 100 points
Part Number: MSP430FR5969
Other Parts Discussed in Thread: MSP-EXP430FR5969

Environment: IAR for MSP430 (full version) - debugging code on Launchpad MSP-EXP430FR5969

Hardware configuration: DCO = 16MHz, 0 wait states on FRAM (also experimented changing this to no effect)

Simple task: Toggle a GPIO pin as fast as possible

Emitted assembler from IAR:

??tleReadFactory_0:
XOR.B #0x80, &0x202
JMP ??tleReadFactory_0

This should take 8 instruction cycles - 5 for the xor and 3 for the jmp - verified with the cycle counter on the EEM

When I look at the pin with a scope, the pin toggles every 1usec - exactly twice the expected interval of (1/16MHz)*8 = 500usec

It isn't FRAM wait states as I tried changing them which confirms that I am probably at 100% on the cache hits which makes sense given it is just a tiny little loop

Verified the DCO via SMCLK with 2 prescale and output to a pin. changing the DCO changes the interval as expected with the factor of 2 conserved.

Looking for ideas of where else to look for the timing leak. Does the embedded emulation add that much overhead?

  • 0
    TI__Mastermind 49692 points

    Hi Edwin,

    First, I'd strongly recommend using wait states if your SMCLK or MCLK is above 8 MHz, as pointed out in Table 5.3 in the datasheet. Perhaps, you're dividing (DIVS) the 16 MHz DCO by 2, which would make SMCLK or MCLK equal to 8 MHz and which could be why the wait states don't change anything. Can you confirm if this is the case?

    Also, the MSP430FR5xx/6xx devices have a hardware cycle counter. However, the measured cycles can be slightly off due to releasing/reclaiming the device from/back under debug control. This is mentioned on page 8 in the Advanced Debugging Using the Enhanced Emulation Module (EEM) With Code Composer Studio Version 6 app note.

    In case you're not aware of this, the FRAM accesses are only subject to the 8 MHz access limitation. Using wait states and a higher frequency system clock like 16 MHz can boost performance. However, the 16 MHz system clock frequency doesn't result in a FRAM write speed that's twice as fast (not proportional increase). This is because the accesses to the RAM and the instruction fetches in the cache are executed more quickly. Strategies such as leveraging DMA and increasing the system clock frequency can be found in the Maximizing Write Speed on the MSP430™ FRAM app note.

    Lastly, if your application requires a PWM output, check out the PWM modes of the Timer_A and Timer_B modules. These modes require no CPU intervention. See Section 19.1 in the User's Guide.

    Regards,

    James

    MSP Customer Applications

  • 0
    Guru 302100 points
    To toggle a pin as fast as possible, use a timer, or configure a pin to output the clock signal.

    Anyway, how does the output look when you put two XORs in the loop?
  • 0 in reply to James Evans
    Prodigy 100 points
    I am aware of the wait state requirement for the DCO at 16MHz but right now it isn't a problem and I am not in Production so it is on the list.

    I use the following command to configure SMCLK & MCLK:
    CS_initClockSignal( CS_SMCLK, CS_DCOCLK_SELECT, CS_CLOCK_DIVIDER_2 );
    CS_initClockSignal( CS_MCLK, CS_DCOCLK_SELECT, CS_CLOCK_DIVIDER_2 );

    And now I see what is going on. Not sure how that MCLK crept in there. Thank you for the help!

    I will accept this answer. Cheers! Ed
  • 0 in reply to Clemens Ladisch
    Prodigy 100 points
    Clearly a hardware timer is the way to go for twiddling a GPIO fast. I am poking around a software implemented I2C (non-compliant device) and wanted to get an idea about possible bitrates. That was when I saw the timing mismatch (see above for the reason). Regardless, it looks like software is going to be too slow.

    But I did run the double XOR out of curiosity and it takes a little less time to get two edges and it is not longer symmetric (because of the jmp time)
  • 0 in reply to Edwin Maynard
    Prodigy 100 points
    I changed the wait states and the MCLK divisor and it performs exactly like it should. An object lesson in having other people check your code - the MCLK configuration was a holdover from code that I was cribbing from. Thanks all for the help!
  • 0 in reply to Edwin Maynard
    TI__Mastermind 49692 points
    Excellent! Thanks for letting us know that the issue has been resolved and for marking the thread as "Answered".

    Regards,

    James

    MSP Customer Applications

**Attention** This is a public forum