Jump to content
Sign in to follow this  
CrappoMan

__delay_cycles on G2553 @ 16Mhz Problem

Recommended Posts

I'm having a problem getting my G2553 running at 16Mhz. I'm using grace to set the DCO to 16Mhz.

 

The debugger gets stuck at the __delay_cycles(100000) instruction in BCSplus_init.c:

    if (CALBC1_16MHZ != 0xFF) {
       /* Adjust this accordingly to your VCC rise time */
       __delay_cycles(100000);
       /* Follow recommended flow. First, clear all DCOx and MODx bits. Then
        * apply new RSELx values. Finally, apply new DCOx and MODx bit values.
        */
       DCOCTL = 0x00;
       BCSCTL1 = CALBC1_16MHZ;     /* Set DCO to 16MHz */
       DCOCTL = CALDCO_16MHZ;
   }

If i change it to a smaller value, say 10000, it works fine.

 

The function is compiled into this:

31              __delay_cycles(100000);
0xC05E:   120D                PUSH    R13
0xC060:   403D 8233           MOV.W   #0x8233,R13
       1_$2:
0xC064:   831D                DEC.W   R13
0xC066:   23FE                JNE     (1_$2)
0xC068:   413D                POP.W   R13

 

Stepping through the routine, and using the Register Window, I can see that R13 gets loaded with 0x8233 and decremented correctly, but If I press "Run" and then press "Pause", sometimes R13 is smaller and sometimes larger. It never exits the loop as it never gets to zero.

 

This happens both during debugging and running on the chip.

 

If I directly change R13's value to 2, it loops twice and continues correctly.

 

And to make things stranger, if I change the DCO to 1Mhz (to avoid the call to __delay_cycles() in BSCplus_init.c) and add a call to __delay_cycles() in main:

void main(void) {	
WDTCTL = WDTPW + WDTHOLD;             // Stop watchdog timer

__delay_cycles(100000);

CSL_init();                       // Activate Grace-generated configuration
...

The __delay_cycles() call works perfectly ???

 

Does anyone know why R13 is acting strangely when DCO is set to 16Mhz ? And why it works with a value of 10000 but not 100000 ?

Share this post


Link to post
Share on other sites

Yes, a watchdog interrupt and a pin change interrupt.

 

Watchdog is interrupting at ~30ms @ 1Mhz DCO. Don't know about @16Mhz, cos it won't get any further than CSL_init();

The pin change interrupt isn't being used at the moment, until I get the speed working correctly.

Share this post


Link to post
Share on other sites

I assume you mean that 10,000 cycles is less than the watchdog timeout (32768 cycles), whereas 100,000 cycles is more so the watchdog is firing and interfering, but in my original post, i showed that the watchdog timer is disabled before the calls to __delay_cycles() or CSL_init(), so it cant be the watchdog interrupt interfering with R13.

 

void main(void) {   
  WDTCTL = WDTPW + WDTHOLD;             // Stop watchdog timer
__delay_cycles(100000);
  CSL_init();                       // Activate Grace-generated configuration
...

Correct me if i'm wrong.

Share this post


Link to post
Share on other sites

Hi,

 

I don't know the protoype of the fonction __delay_cycles (?). May be you have to enter an int. And then you cause a overflow with 100000.

It's just a idea. :D

 

Good luck

Share this post


Link to post
Share on other sites

I dont know either, but I've worked out that the value of R13 is set to "(cycles - 7) / 3". I've tested this with a few different values and it seems to be correct.

 

The value of 100,000, is supplied by 'grace', not by me.

 

I've hooked up my scope (Tektronix 2245A, 100Mhz, Quad trace, with cursors and measurements) and it all works ok if I comment out the __delay_cyles() call in BCSplus_init.c, or I use manual frequency selection with:

	BCSCTL1 = CALBC1_16MHZ;     /* Set DCO to 16MHz */
DCOCTL = CALDCO_16MHZ;

It was a struggle getting it to run at 16Mhz using 'grace' and the fact is: IT DOESNT WORK!

Share this post


Link to post
Share on other sites

@CrappoMan, I missed that part of your code and you are correct, it can't be watchdog.

@aymeric, that function takes long, so it can't be overflow.

Share this post


Link to post
Share on other sites

I think you need to perform a sanity check on the DCO constants right about now.

 

Why don't you run the sample program msp430g2xx3_clks.c and scope out P1.0, P1.1 and P1.4 to see if you get the correct frequencies? Sample programs for the G2553 are located here.

 

P1.0 = 32.768kHz

P1.1 = DCO/10

P1.4 = DCO (1MHz default)

 

If they check out at 1MHz then tweak the DCO settings back up to 16MHz and verify that P1.4 gives you a 16MHz pulse train.

 

If it doesn't check out then the DCO constants must be re-calibrated.

Share this post


Link to post
Share on other sites

I have tried the example code, (btw, didn't know example code was available for the MSP430G2xx3 series, I only had example code for the xx1 and xx2 series).

 

I don't have the 32Khz crystal connected, but that should only affect the ACLK output.

 

At 1Mhz, all checks out ok, got 1Mhz and 100Khz pulse trains.

 

At 16Mhz, I get ~1.6Mhz (1.552Mhz actual) pulses on P1.1:

P1116Mhz.jpg

 

But, a ~16Mhz SINE WAVE (sort of!!!) on P1.4:

P1416Mhz.jpg

 

Is it supposed to be a square wave or is the approx sine wave ok ? Or is the sine wave a byproduct of my scope probe capacitance ?

Share this post


Link to post
Share on other sites

Is it supposed to be a square wave or is the approx sine wave ok ? Or is the sine wave a byproduct of my scope probe capacitance ?

 

You might want to build one of these:

http://koti.mbnet.fi/jahonen/Electronics/DIY%201k%20probe/

 

I can post some comparison shots from my old Tek TDS460A tomorrow. The only tricky part with that kind of probe is that you either need a 50 Ohm terminator or a scope that has an internal 50 Ohm setting (like mine :) )

Share this post


Link to post
Share on other sites
...Is it supposed to be a square wave or is the approx sine wave ok ? Or is the sine wave a byproduct of my scope probe capacitance ?

 

There are two things affecting the shape of the wave.

First, as you have already suspected it, is the scope and the probe. At 16MHz, response times, capacitance, inductance, all matter.

Second, the reason why this chip is limited to 16MHz is because of the rising and falling times. Basically, if the clock (and other logic) was producing a square wave, then there will be no clock frequency limit. This is related to the technology that was used to produce the chip.

Share this post


Link to post
Share on other sites

Is it supposed to be a square wave or is the approx sine wave ok ? Or is the sine wave a byproduct of my scope probe capacitance ?

 

You might want to build one of these:

http://koti.mbnet.fi/jahonen/Electronics/DIY%201k%20probe/

 

I can post some comparison shots from my old Tek TDS460A tomorrow. The only tricky part with that kind of probe is that you either need a 50 Ohm terminator or a scope that has an internal 50 Ohm setting (like mine :) )

 

Ok, as promised, here are the scope traces for a standard 350Mhz 10:1probe (Channel 2) and a "homebrew" 20:1 probe (channel 4). Both probes were looking at the same pin. The scope used is an old Tek TDS 460A and the Bandwith was limited to 100Mhz.

 

 

1_Mhz.png

 

On a 1Mhz clock, the 10:1 probe shows a little overshoot, but not much distortion.

 

16_Mhz.png

 

On the 16 Mhz Clock signal, the 10:1 Probe shows significant distortion and overshoot due to it's capacitance. The 20:1 probe shows a nearly trapezoidal wave shape with no overshoot in the corners. I think a couple of these probes would be a useful addition to all of our toolboxes.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...