External Clock Replication using CLKOUT

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

 

I've seen that there are a couple of threads on the matter of CLKEVOUT register, but I couldn't get it to work on my example.

 

Before I start, let me just quickly mention that I first posted the question over at the MikroE forum, the creator of the development board I'm using to work on Xmega 128A1, here:

 

https://forum.mikroe.com/viewtop...

 

Since no one is responding, I hope you won't mind me repeating the question here.

 

Here is the situation: the controller gets 8 MHz from the external crystal. After the corresponding set-up (oscilloscope used to confirm it works), I would like to get a copy of this clock signal at the PE7 pin. So what I did was:

PORTE_DIRSET = 0xFF
PORTCFG_CLKEVOUT = 0x03

as instructed by pp. 146-147 of the Xmega 128A1 manual.

 

All I get at PE7 is a lot of noise at 200 ns time scale. The same happens for PC7 and PD7, where, of course, CLKEVOUT is set to 0x01 and 0x02, respectively.

 

I guess I am overseeing something obvious, my apologies for inconvenience, but I would highly appreciate any help provided. Thanks in advance.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not familiar with this specific chip (but I did review the manual pages you referenced), but I have recently been dealing with the same feature on an E5.  In light of my experience with that, try:

 

  • Ensure you don't have any other peripherals enabled that may be overriding the clock output on the pin
  • Configure port e as an output / general I/O and set bit 7 to 1.  Trap execution in an endless loop immediately after and verify with your scope the pin voltage is high.
  • After setting up everything the way you believe it should be, read back the configuration registers and output them via whatever means you have (LEDs, console, debugger, etc) to ensure that they are actually set the way you expect.  One of the troubles I was having was that a configuration register (not the one we're discussing) was protected by the CCP, and it wasn't immediately obvious in the manual that it was.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello SolarFreak,

 

thank you very much for the ideas.

 

I confirmed that the above code sets CLKEVOUT correctly to 0x03 in the case of PORTE, of course. Therefore, this register is not protected by CCP.

 

The PORTE setup as the output port is also confirmed (by reading PORTE_DIRSET).

 

I am not sure how to "Ensure you don't have any other peripherals enabled that may be overriding the clock output on the pin" - namely, the chip gets a clean start and provided the whole code compiled and uploaded. Only the bootloader exists in there besides what is written in the first post. By default nothing should be running just like that. Or am I maybe wrong here - is there a way to somehow scan the peripherals and show what is on and where?

 

Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

barjaktar wrote:
"Ensure you don't have any other peripherals enabled that may be overriding the clock output on the pin"
Well start with an "empty" program that does nothing else.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi clawson, thanks.

 

In that case, it is already ensured - here is the complete code:

// ----- External Clock selection procedure!!!
   OSC_XOSCCTRL = 0x40;   // freq. range 2 - 9MHz; External Clock
   OSC_CTRL |= 0x08;      // enable external oscillator

   while(XOSCRDY_bit == 0)
    ;

   CPU_CCP = 0xD8;  // The CCP register must be written with the correct signature to enable change of the protected
                    // I/O register or execution of the protected instruction for a maximum of 4 CPU instruction cycles.
   CLK_CTRL = 3;    // External oscillator
// ---------------------------------

UARTC0_Init(19200);
Delay_ms(1000);

PORTE_DIRSET = 0xFF
PORTCFG_CLKEVOUT = 0x03

while(1){
    UARTC0_Write(PORTCFG_CLKEVOUT);
    UARTC0_Write(PORTE_DIR);
}

Thanks a lot, looking forward to your help.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some more thoughts...

 

  • Try outputting the clock on PC7 and PD7, see if you get different results.
  • Could it be your scope?  Or the way you have it setup?  Trigger levels, time base, etc. From my experience outputting the clock, the waveform you're going to see looks more analog than digital.  Try probing the crystal and make sure you can see what you expect there.
  • It's broken.  I say that half joking, however...  On the board I've been experimenting with, there is the option for 4x, 2x and 1x clock output.  1x and 4x work fine, 2x gives me nothing.  This is changing no other parameters other than the couple of bits that select it.

 

I do assume correctly that the USART is working without issue and that's how you verified the register settings in the code above?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello SolarFreak, thanks.

 

I already tried PC7 and PD7, by setting:

PORTC_DIRSET = 0xFF
PORTCFG_CLKEVOUT = 0x01

for port C and:

PORTD_DIRSET = 0xFF
PORTCFG_CLKEVOUT = 0x02

for port D. Unfortunately, to no avail - the same thing happens.

 

The scope works fine, because I tried outputting a simple clock in a brute force way:

PORTE_DIRSET = 0xFF;
Delay_ms(10);
PORTE_OUTSET = 0xFF;
Delay_ms(10);
PORTE_OUTCLR = 0xFF;

and that shows a very nice 20 ms period pulse.

 

Finally, yes, USART is working like a charm, I can read anything via RealTerm.

 

Ok, well, thanks for everything - the third option might not be incorrect. It is an old development board sitting on the shelf for at least five or six years, who knows what could've happened to it. The point of the thread was to make sure that I am doing everything I should be doing.

 

In that context, can anybody confirm that they actually managed to copy the 8 MHz input external clock to the PD7/PE7/PC7 pin of Xmega 128A1 as the peripheral clock?

 

Thanks.