Hi.

I am developing some code and need to know what values are loaded into the mbed for programs compiled. I konw you have the basic 'startup' of the PLL, etc. via a linked .o file, but I cannot find any reference to what the values are.

Specifically, I need to know what cclk is, and the pclks for the timer 1 and A/D converter.

Thanks!

Jim

If you need the Cortex-M3 part, see SystemInit() function in the CMSIS package (\CMSIS_V1P30\CM3\DeviceSupport\NXP\LPC17xx\system_LPC17xx.c). The values in the source file match those of mbed except for PLL0CFG_Val=0xb and PLL1_SETUP=0.

Igor,

Thank you very much for your prompt, and very helpful, reply.

Indeed, it is for the Cortex-M3, and I just did not know what defaults they used in the linked startup file.

Based upon the file, and your corrections you noted, I see that the part is running a cclk of 72 MHz., and all of the peripherals in PCLKSEL0 are running at 18 MHz.

Thanks again!

Jim

72MHz? Surely not.

A previous post from Chris (title mbed CPU speed, extract below) stated it was running at 100MHz.

The LPC1768 is being clocked at 100MHz. However, we do have an LPC2368 version from the beta trial that was clocked at 60MHz, so I susepct this is where the confusion has crept in.

Cheers,
Chris

Paul

Well, I don't have the new mbed (yet) so I can't check but that's what I see in the object files. You can check it yourself - call SystemCoreClockUpdate() and print the value of SystemCoreClock.

Hi All,

The facts are actually:

• LCP2368 mbed - 60MHz
• LPC1768 mbed - 72MHz

It is quite easy to verify this for yourself, as CMSIS defines a variable called SystemCoreClock that holds the current core frequency:

#include "mbed.h"

int main() {
    printf("SystemCoreClock = %d Hz\n", SystemCoreClock);
}

SystemCoreClock

When we were doing our initial prototype we certainly had it running at 100MHz, but then we just used the default CMSIS layer when we went live which sets it at 72MHz. Unfortunately, CMSIS doesn't provide an easy way to just set it at random frequencies, but in most cases having it fixed is probably not a problem (a feature we could perhaps suggest get added to CMSIS).

But regardless, who wants me to beef it up to 100MHz?!!

Simon

Also, regarding the questions around the PCLK, they are all just set by default to /4:

LPC_SC->PCLKSEL0  = 0;
LPC_SC->PCLKSEL1  = 0;

Again, you can dive in and read these values at runtime yourself (or any for that matter if you like reading datasheets). If you create and use library components, they may modify them of course (in this case AnalogIn doesn't, but it could well do).

Simon

I feel cheated. I thought I was getting a microcontroller running at 100MHz. It is like buying a car and then being told that you cannot use top gear!

I suggest you resolve this issue before people start quoting the Sales of Goods Act (misrepresentation).

Paul

Hi Paul,

Paul Griffith wrote:
I feel cheated. I thought I was getting a microcontroller running at 100MHz. It is like buying a car and then being told that you cannot use top gear!

Well, to complete the analogy, you got the car, just haven't put it in to top gear yet :D

We'll aim to fold it in to the next library release. Then you can really burn rubber!

Simon

Simon,

Thanks for all the information. I had already determined that we had the default of all pclks being set to the default cclk/4. The only unknown was the PLL0 settings. I knew I had read in an earlier post that you were running at 100 MHz., but in my testing, saw is was a wee bit slower than that. Not a problem for me...just had to know what it was.

To those that want to run the part at a higher speed, it is not too diificult to re-set the PLL0 for a faster speed.  It is only a couple of C-code lines that load the appropriate PLL0 configuration registers, wait for the lock, then re-load. This, does, however, affect many of the standard mbed library functions, such as the wait() function, so the users must be aware of what they are doing if they go that route. I am sure you guys will make it seamless when you fold it into the next library release, though.

Jim

Excellent, let's see what the beast can do!

Seriously, mbed is an excellent concept, which I think could go a lot further than you guys appreciate. Don't sell it short by only running at 3/4 throttle!

If you are going to play around with clock speeds, it would be nice to have an API call to set the clock speed on demand. Not everybody wants to burn rubber; some may appreciate a leisurely stroll with lower power consumption. Being able to put the device to sleep (with wake on event/interrupt) could also be useful.

Paul

Sleep has been discussed here, with some code.

It kind of sucks how this wasn't revealed earlier.. I mean, not that its a big difference, but it is somewhat of an important selling point...

Hi all,

I've just been looking at increasing the clock speed for the LPC1768 M3 mbed Microcontroller, and think there may be a more intelligent choice that just going straight for 100MHz...

Whilst the part is specified at 100MHz, I'm wondering whether to actually run it at 96MHz by default. The main reason being that when you come to use USB, you need a 48MHz clock. With the core running at 96Mhz, that would mean it'd be possible to run them both off the same PLL (which we'd run at e.g. 288Mhz).

However, given there was outrage(!) that it isn't running at 100MHz already, I thought it'd be worthy of a brief consultation first :P

I'd also make it clear in documentation that we were running it at 96Mhz (distinct from the more general LPC1768 MCU "up to 100MHz" specs).

Sound ok? (Particularly Paul, Igor)

Simon

Haha!
I feel kinda bad now..

96MHz should do nicely.. :) 

Hi Simon,

96MHz is very acceptable.

While you are working on this, how about an API to support on demand changes of CPU clock frequency?  I am thinking along the lines of a set of preset frequencies such as 96, 72, 48, 24, 12, 6, 4 and 2MHz. These frequencies should also give accurate baud rate dividers for the UARTs.

BTW, I realise USB won't work if CPU clock is less than 18MHz.

Paul

PS I don't feel bad. The gripes were justified. If we hadn't made a fuss, it is likely nothing would have been done ;)  Having said that, I award the mbed team a Gold Star for their excellent response!

Hi all,

Simon said, that hardware of LPC1768 mbed use 72MHz clock.

I was found in user manual of LPC17xx section 5.12.

5.12 Examples of PLL0 settings
The following table gives a summary of examples based on different system requirements.
Table 27. Summary of PLL0 examples
Example Description
1 • The PLL0 clock source is 10 MHz.
  • PLL0 is not used as the USB clock source,
  • The desired CPU clock is 100 MHz.
2 • The PLL0 clock source is 4 MHz.
  • PLL0 is used as the USB clock source.
  • The desired CPU clock is 60 MHz.
3 • The PLL0 clock source is the 32.768
  • PLL0 is not used as the USB clock source,
  • The desired CPU clock is 72 MHz.

Simon, is it truth, that HW of LPC1768 mbed use example number 3?

Hi,

Here is a simple program to dump them out. It'll also show the changes made when I bump the LPC1768 frequency up.

#include "mbed.h"

int main() {
    int Fin = 12000000; // 12MHz XTAL
    
    printf("PLL Registers:\n");
    printf(" - PLL0CFG = 0x%08X\n", LPC_SC->PLL0CFG);
    printf(" - CLKCFG  = 0x%08X\n", LPC_SC->CCLKCFG);
    
    int M = (LPC_SC->PLL0CFG & 0xFFFF) + 1;
    int N = (LPC_SC->PLL0CFG >> 16) + 1;
    int CCLKDIV = LPC_SC->CCLKCFG + 1;

    printf("Clock Variables:\n");
    printf(" - Fin = %d\n", Fin);
    printf(" - M   = %d\n", M);
    printf(" - N   = %d\n", N);
    printf(" - CCLKDIV = %d\n", CCLKDIV);

    int Fcco = (2 * M * 12000000) / N;
    int CCLK = Fcco / CCLKDIV;

    printf("Clock Results:\n");    
    printf(" - Fcco = %d\n", Fcco);
    printf(" - CCLK = %d\n", CCLK);    
}

PLL Registers:
 - PLL0CFG = 0x00000013
 - CLKCFG  = 0x00000007
Clock Variables:
 - Fin = 12000000
 - M   = 20
 - N   = 1
 - CCLKDIV = 8
Clock Results:
 - Fcco = 480000000
 - CCLK = 60000000

PLL Registers:
 - PLL0CFG = 0x0000000B
 - CLKCFG  = 0x00000003
Clock Variables:
 - Fin = 12000000
 - M   = 12
 - N   = 1
 - CCLKDIV = 4
Clock Results:
 - Fcco = 288000000
 - CCLK = 72000000

Thank you, Simon.

This is good, values needed by my programs. It will be no dangerous for me from now.

Any power consumption issues running at 96 or 100MHz? External power supply required?

Looking at the mbed schematic, I see 12MHz as an input connected to pin 22 (X1), but I do not see a source for 12MHz. Is there an OSC1 that is not shown on the schematic?

Hi,

I've just updated the library to v19, which includes increasing the frequency of the mbed LPC1768 to 96MHz. To update to the new library, click on it in your filetree and select "Update to latest version".

Now if you run the following on a LPC1768 with the new libraries, you should get 96000000 Hz:

#include "mbed.h"

int main() {
    printf("SystemCoreClock = %d Hz\n", SystemCoreClock);
}

This update should be totally transparent as the mbed libraries take this change in to account; i.e. all code should run as normal. Please report any problems if you see them.

Hopefully this gives you the extra horsepower some of you were after!

Thanks,
Simon

Looking at the mbed schematic, I see 12MHz as an input connected to pin 22 (X1), but I do not see a source for 12MHz. Is there an OSC1 that is not shown on the schematic?

 

I don't think this question has been answered. Is the schematic diagram mbed-005.1.pdf complete?

Where is the 12 MHz crystal near pin1 of the LPC1768 shown on the schematic?

What is the ATMEL0935 part on the bottom of the board? Flash?

Thanks

John.

1. Top of the board in the corner with the chrome top. (next to p22)

2. Yup the SPI flash in the mbed interface.

Thanks for the reply. Three more questions:

1) Do you know whether a complete schematic will be made available?

2) Is there any documentation available that specifies the register settings that are made during system startup?

3) Can these settings be changed in 'user' code after initialisation, for instance if a polarity is to be reversed or something similar?

John.

Hi John,

John Robbins wrote:
1) Do you know whether a complete schematic will be made available?

John Robbins wrote:
2) Is there any documentation available that specifies the register settings that are made during system startup?

John Robbins wrote:
3) Can these settings be changed in 'user' code after initialisation, for instance if a polarity is to be reversed or something similar?

Simon

Hi Simon,

I think it would be a good idea to first focus on a reference design that supports porting code developed on mbed to a LPC1768 stand alone prototype. You went a long way with your Users » chris » Notebook » Prototype to hardware post, but the details,decoupling, pullups etc. of the micro controller schematic were missing.

The idea of a standard programming port is good, but I am not happy about your choice of connections. You need three pins for the serial I/O (TX, GND, and RX), two pins for ISP, and two pins for Reset. In your scheme I ran out of Grounds.

Again the Reference Design should specifically support the porting of Hex or Binary files from mbed to the stand alone prototype.

John

I'd just like to add to the (old) duscussion at bit.

In Simon's comment above he states:-

Also, regarding the questions around the PCLK, they are all just set by 
default to /4:

However, after doing some poking around I find that PCLKSEL1 was in fact 0x0 until I defined Serial test(p28, p27)

By defining that it switches on Uart2. But then I found the DLM and DLL values to be out by a factor of 4. That's because when the Uart2 is enabled by the library, PCLKSEL1 suddenly sets PCLK_UART2 (17:16) to "01".

In other words, the PCLK applied to Uart2 is switched to CCLK/1 and not CCLK/4 as expected from Simon's statement that all PCLK were /4 by default.

Maybe I am mis-interpretting what is meant by "default". Afaict, "default" means "after boot" and not "our libs use this by default"

Hi Andy,

Yep, the PCLK defaults that the LPC1768/2368 comes up with after reset are /4, and we don't fiddle with them during startup. However, if you use an mbed interface to drive a peripheral, we certainly may choose to change the PCLK for that specific interface; for example, to reach a requested high baudrate.

You can take a look at the power and clocking control section in the LPC1768 manual for all the gory details, linked off:

• LPC1768 Technical Reference

Hope that clarifies things.

Simon

Hi Simon,

I have the manual thanks, and have (for about 50%) read in detail and continue to do so :)

I was just pointing out the simple fact that while trying to setup my system for CCLK/4 it didn't work until I looked and found for myself that the blanket statement made in the forum (rather than any techincal reference I was able to find) was incorrect.

I have seen and read and, so far not added, to the forum posts regarding the open sourcing of the mbed libs. While I have considerable experience of both closed and open source, I still find Mbed libs to be "grey wanna bees" open source. I understand why they are not. But at the same time, when the libs do "unexpected" things due to lack of documentation, I am so use to providing a patch to the aurthor for consideration that I find this "reduce to bare min example and post to a forum" somewhat alien. Why? Well, for closed source I have a contact, I can describe the problem and THEY reduce to minimum and investigate. They sort the problem as I paid them for the libs. With Mbed, I really don't expect to have to reduce a problem myself and post a forum. I don't mind posting problems to a forum, but I do so with a patch fix when I do. With Mbed, I can't. As an embedded software engineer/developer, I'm reduced to being a simple  end user/forum poster with a problem and no solution. I like problems, but I like solutions more :)

Forgive me but, out of the box, Mbed is a great product and well supported. I'm just not use to have to writing a ton of code that uses LPC17xx.h to figure out "what just happened" than just read the code that tells me "what is about to happen".

You have to remember, closed source libs require a) huge documentation and b) hugh support. Both require resources and thats where closed source companies provide great support, they're paid to. But here I find myself with a really good little product (the Mbed) that, like I said, out of the box is proving to be a potential winner for it's creators. I have made great progress with it. Where I have stumbled so far is lack of docs/support. Luckily I have many years of embedded systems experience and can find my way round a 600+ page manual with LPC17xx.h. But if you really want to bring in new blood then, imho (and truely my own imho) you need to open up more on the code side.

Happy to disuss more, but public forums suck at this sometimes.

thanks for the reply anyway,

--Andy