DogEars
Posts: 44
Joined: Sun Jun 17, 2012 1:16 pm

General Purpose Clock Voltage

Fri Jul 13, 2012 9:23 pm

I'm experimenting with using the GPCLK0 to supply the master clock to an external DAC, but when checking the voltage on a scope it's very low around 0.2 volts, is this expected?

User avatar
Gert van Loo
Posts: 2487
Joined: Tue Aug 02, 2011 7:27 am
Contact: Website

Re: General Purpose Clock Voltage

Fri Jul 13, 2012 9:47 pm

What frequency?
The GPIOs can only switch to about 75 MHz producing a reasonable square wave. Above that the output starts looking more and more like a sine wave. And even those numbers depend on your load (mostly capacitive load).

DogEars
Posts: 44
Joined: Sun Jun 17, 2012 1:16 pm

Re: General Purpose Clock Voltage

Fri Jul 13, 2012 9:54 pm

Gert van Loo wrote:What frequency?
I've got it running at 10Mhz just to test it's coming out on the pin I thought it should be on (P1-07 on the header?)

ksangeelee
Posts: 192
Joined: Sun Dec 25, 2011 5:25 pm
Location: Edinburgh, UK
Contact: Website

Re: General Purpose Clock Voltage

Fri Jul 13, 2012 11:01 pm

Gert van Loo wrote: The GPIOs can only switch to about 75 MHz producing a reasonable square wave. Above that the output starts looking more and more like a sine wave.
I always seem to get more of a sine wave even at lows of 7.5 MHz - this is from C via mapped memory in a tight loop compiled with -O0 (e.g. while(1) { on; off; }.

I noticed that the PADS registers show SLEW is 'on' for all pins, and it's my understanding that this would affect the voltage rise and fall times of output pins. Is this correct?

Edit: Coincidentally I've since read one of your posts that explains the drive-current/capacitor relationship to rise/fall time, though I'd still be interested to know the effect of the SLEW bit.

User avatar
jbeale
Posts: 3733
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: General Purpose Clock Voltage

Fri Jul 13, 2012 11:31 pm

Sorry if this is obvious, but you want to make sure you are using a 10x probe with a good frequency rating. If you use a 1x probe you won't see much signal amplitude above 5 MHz.

ksangeelee
Posts: 192
Joined: Sun Dec 25, 2011 5:25 pm
Location: Edinburgh, UK
Contact: Website

Re: General Purpose Clock Voltage

Fri Jul 13, 2012 11:48 pm

jbeale wrote: Sorry if this is obvious, but you want to make sure you are using a 10x probe with a good frequency rating. If you use a 1x probe you won't see much signal amplitude above 5 MHz.
Many thanks, that sounds suspiciously familiar, and reading about capacitance of x1 probes it starts to make sense (as do Gert's references to capacitive loads).

ksangeelee
Posts: 192
Joined: Sun Dec 25, 2011 5:25 pm
Location: Edinburgh, UK
Contact: Website

Re: General Purpose Clock Voltage

Sat Jul 14, 2012 1:57 am

ksangeelee wrote: I noticed that the PADS registers show SLEW is 'on' for all pins, and it's my understanding that this would affect the voltage rise and fall times of output pins. Is this correct?
... though I'd still be interested to know the effect of the SLEW bit.
Of course, had I read the pads control page properly, I'd have understood that 1 means 'slew rate not limited'. Tsk.

DogEars
Posts: 44
Joined: Sun Jun 17, 2012 1:16 pm

Re: General Purpose Clock Voltage

Mon Jul 16, 2012 11:06 am

Without load, and I'm assured we're using the correct probes (it's not actually me that doing the measurement as I'm many miles away from hardware that's running the code!) we get approx 0.1 volts and a very noisy square wave!

Does this code look correct, should we be doing something with pull up/down registers?

Code: Select all

#define GP_CLK0_CTL *(clk + 0x1C)
#define GP_CLK0_DIV *(clk + 0x1D)
printf("Configure General Purpose Clock");
	GP_CLK0_CTL = 0x5A000001;
	GP_CLK0_DIV = 0x5A000000 | 1<<12 | 0xB36;   // divider = 1.70068359375 = b1.101100110110 ( 11.289578 MHz)
usleep(10);
GP_CLK0_CTL = 0x5A000011;

User avatar
Gert van Loo
Posts: 2487
Joined: Tue Aug 02, 2011 7:27 am
Contact: Website

Re: General Purpose Clock Voltage

Mon Jul 16, 2012 4:49 pm

I need more then that.
What is the value of your 'clk'.
Also where do you set the GPIO output mode to GPCLK0?

DogEars
Posts: 44
Joined: Sun Jun 17, 2012 1:16 pm

Re: General Purpose Clock Voltage

Mon Jul 16, 2012 10:13 pm

Gert van Loo wrote: What is the value of your 'clk'.
The code is from one of you examples.

Code: Select all

#define BCM2708_PERI_BASE        0x20000000
#define CLOCK_BASE               (BCM2708_PERI_BASE + 0x101000) /* Clocks */

clk_map = (unsigned char *)mmap(
      (caddr_t)clk_mem,
      MAP_BLOCK_SIZE,
      PROT_READ|PROT_WRITE,
      MAP_SHARED|MAP_FIXED,
      mem_fd,
      CLOCK_BASE
   );
 clk = (volatile unsigned *)clk_map;
Gert van Loo wrote:Also where do you set the GPIO output mode to GPCLK0?
Other than setting the ENAB bit 4 and the source to the crystal, what else do I need to do, as I understand it the GPCLK0 is the default function for pin P1_07 on the header, is that not correct?

Code: Select all

GP_CLK0_CTL = 0x5A000011; // Source=osc and enable
Also I can't see any examples of where people are checking the BUSY flag as mentioned in the docs, is this required ?

Many thanks for your help with this,
Graeme.

User avatar
Gert van Loo
Posts: 2487
Joined: Tue Aug 02, 2011 7:27 am
Contact: Website

Re: General Purpose Clock Voltage

Tue Jul 17, 2012 8:26 am

Other than setting the ENAB bit 4 and the source to the crystal, what else do I need to do, as I understand it the GPCLK0 is the default function for pin P1_07 on the header, is that not correct?
No, that is not correct .The default mode for any GPIO after a reset is in general purpose input.
This can be override by SW. GPIO 14&15 are set into UART mode by the Linux kernel and some of
the new SPI/I2C device drives switch some GPIO pins to their ALT mode.
If you want the clock mode you have to program it into its ALT-mode.
See my example code for the PWM and the SPI interfaces.

I still have to check the address you are writing to but I am off to work now.

DogEars
Posts: 44
Joined: Sun Jun 17, 2012 1:16 pm

Re: General Purpose Clock Voltage

Tue Jul 17, 2012 3:53 pm

We're setting the function explicitly now, but it only seems to actually start intermittently!

Code: Select all

	// SET THE GPCLK0
	INP_GPIO(4);
	SET_GPIO_ALT(4,0);
But we're only getting approx. 2.5KHz not what we're aiming for

Code: Select all

	GP_CLK0_DIV = 0x5A000000 | 1<<12 | 0xB36;   // divider = 1.700683594 = b1.101100110110 (11.289577 MHz)
What are we doing wrong?

Cheers,
Graeme

DogEars
Posts: 44
Joined: Sun Jun 17, 2012 1:16 pm

Re: General Purpose Clock Voltage

Tue Jul 17, 2012 8:31 pm

This is the address and values after configuring the clocks: They seem to be correct?

Does this BUSY flag mentioned in the docs actually work, I've tried disabling the clocks and waiting for the BUSY flag to be zero and it doesn't happen, no one seems to be using it in any code examples I've seen.

GP Clock Address
Control Register address =0x01475070: 0x00000091
Divider Register address =0x01475074: 0x00001b36
PCMCTRL Register address =0x01475098: 0x00000091
PCMDIV Register address =0x0147509c: 0x0000d9b0

Cheers,
G.

DogEars
Posts: 44
Joined: Sun Jun 17, 2012 1:16 pm

Re: General Purpose Clock Voltage

Fri Jul 20, 2012 5:40 pm

I can't seem to get anywhere near 11MHz using the oscillator as the source, but we've figured out that PPLC gives us 400Mhz, could someone give us more information on how to use these clocks, I have a few questions..

Are the clocks fixed? There's some mention of them changing when the system slows down to save power. I think that's one reason the XTAL was suggested as an alternative, or preferred, source.

Does the BUSY flag work, I can't seem to reliably get the clocks to start, some times we need to execute the program a second or third time to get the clock frequency to change. I've tried looping & a usleep until the busy flag is zero, but it just never changes.

Also we can't seem to get anything to work with PPLA I'm guessing this is the 650MHz source in the documents, although it allures to that fact, as far as I can see, it doesn't actually confirm much details about the sources.

Some help with this would be much appreciated.
Many thanks,
Graeme.

DogEars
Posts: 44
Joined: Sun Jun 17, 2012 1:16 pm

Re: General Purpose Clock Voltage

Sun Jul 22, 2012 2:19 pm

bump.

Otto
Posts: 34
Joined: Thu Sep 08, 2011 7:52 am

Re: General Purpose Clock Voltage

Mon Sep 10, 2012 12:56 pm

Any updates on this?

DogEars
Posts: 44
Joined: Sun Jun 17, 2012 1:16 pm

Re: General Purpose Clock Voltage

Mon Oct 01, 2012 11:22 pm

Some more info on this would be great! Are the docs likely to be updated, and from what I can see there is a lot of info missing or incorrect, maybe an updated version is on the horrion?

c g
Posts: 7
Joined: Thu Sep 20, 2012 5:44 am

Re: General Purpose Clock Voltage

Tue Oct 02, 2012 9:03 am

Funny thing is, the only clock sources that I can get working are the crystal@19.2MHz and PLLD@500MHz. The PLL's frequency didn't appear to change with different scaling governors or speed settings in config.txt, therefore I'm going to use this as source for the PCM bitclock. The master or system clock of the DAC in my application comes from its internal PLL, which is supposed to be more accurate than anything that the SoC is able to produce.

You can activate the fractional part of the divisor with the MASH-control bits (bit 9-10) in the respective clock control register. Due to the MASH-divider the resulting frequency will switch periodically around your desired target frequency, noise-shaped, jitter-reduced and claimed to be pushed out of band for audio applications (see BCM-Peripherals manual, p.105). For the I2S interface, I still have to check if the PLL in my DAC would be very happy with that.

For now, I'll stick with the 500MHz and the integer divider. The more interesting part is to get my head around ALSA-drivers.

The missing and incorrect documentation is really frustrating and I wouldn't expect any updates to be released in the near future. This is still a Broadcom SoC and we have to be sooo grateful that we've been provided with that erroneous PDF about the peripherals... I also don't expect anybody from the RPF to be willing and able to spend enough time and provide all the missing bits and pieces.

Return to “Interfacing (DSI, CSI, I2C, etc.)”