LPC1768 - Main Oscillator and UART Question

Development Boards MicroMod
1

Hi,

Please correct me if my understanding of programming the LPC1768 is wrong - there are 2 ways to do it, one via JTAG (OpenOCD), or another way is via through serial communication.

I have chose the latter for my project using USB-to-serial comm - I have soldered an FT2232 together with all the required components and I have both Channel A and Channel B connected to TXD0/RXD0 and TXD2/RXD2 of my LPC1768 processor. Previously, whenever I connected it to the PC, 2 different COM ports will appear, and I had no problems sending data from the PC to FT2232. (I tried to type something from the Hyperterminal and the TXLED for the appropriate channels would light up).

I was more ambitious then and badly wanted to do a simple echo program, where anything I typed would be displayed on the Hyperterminal. As such, I googled for a UART program for LPC17xx, and I found this:

http://code.google.com/p/32bitmicro/sou … ART/?r=116

However, the Makefile, when compiled in my Eclipse, gave me an error about the “include …/Makefile.rules” part. As such, I have used the Makefile by Sagar G V - this is the link: http://code.google.com/p/cortex-m3-tuto … r&can=2&q=

All this while, neither my RTC nor my Main Oscillator (12MHz crystal) was soldered onto the PCB yet.

Unfortunately, although it did work once on Hyperterminal, I was unable to get the COM port for Channel B to appear again. Worst, FlashMagic kept giving me the error “Failed to autobaud” even when I tried to flash via Channel A.

Now, upon reading the LPC17xx manual, it did mention that the LPC17xx would only switch to the main crystal only via software. However, if we try to flash it via FlashMagic, doesn’t FlashMagic require us to define the crystal used - hence, how can they make use of this crystal when it has to be programmed by software? In any case, when I tried probing it using an oscilloscope, the 32.768kHz RTC appeared correctly, but I couldn’t get the 12MHz main oscillator to work. As for the FT2232D, the 6MHz crystal used also appears correctly upon probing using an oscilloscope.

============================================================================

2

The family of LPC17xx parts all start up using the 4 MHz internal oscillator. When you hold P2.10 low during reset they enter the bootloader. The bootloader looks for the ? character, and times the transitions to set the baud rate for download. It responds with “Synchronized”

The bootloader no longer uses the crystal setting.

3

Hi viskr,

Thank you for your response.

I managed to somehow get both channels detected by my PC after removing the EEPROM. It could be that the EEPROM was faulty.

I have also tried reading the user manual for lpc17xx (http://www.nxp.com/documents/user_manual/UM10360.pdf), but being a newbie to this, I have no idea how to “communicate with the bootloader”? Do I use Hyperterminal to send the “?” and if I do so, how do I send a program which activates the main crystal, since flashing it would require another tool (eg. Flash Magic)?

4

You need to write a program that enables the oscillator, and to switch the clock source.

Once you have the program written you can download it with Flash Magic or other utilities.

As for choices in how to write that program, our tools would work for the LPC1768, or Code Red’s Eclipse based version, or Keil’s and others.

5

Hi again,

I am currently equipped with Eclipse Galileo and Codesourcery G++ Lite - hence, I believe the software environment to build a program is somewhat sufficient.

However, I am still unsure how one can activate the main oscillator via software. In NXP’s UM10360, Chapter 3 Section 7, it is mentioned that

“… the main oscillator may not be used at all in some applications, it will only be started by software request. …accomplished by setting the OSCEN bit in the SCS register… The main oscillator provides a status flag (the OSCSTAT bit in the SCS register) so that software can determine when the oscillator is running and stable. At that point, software can control switching to the main oscillator as a clock source.”

SystemInit()
``` function in system_LPC17xx.c does a check if Main Oscillator is enabled, but nowhere in the code do I see how this main oscillator is enabled.

(Sideline a li'l...) Furthermore, everytime I power on my PCB, I am unable to detect any oscillations from my 12MHz crystal. It has a 16pF load capacitance, and I have used 2x 33pF capacitors as X1 and X2 to be connected to my crystal. As for my 32.768KHz crystal, only one leg (pin) shows the correct waveform, while the other does not output the correct waveform. I am using 15pF (x 2) for my 32.768KHz crystal which has a load capacitance of 12.5pF.

Thanks in advance! :)
6

As for the main oscillator the code is probably just checking to see if it has already been enabled, in which case it doesn’t need to do it again, especially as it normally has to wait for the PLL to sync up.

The 32 KHz oscillator is extremely low current so the load of the scope probe is washing out the input side.

7

Hi viskr,

My apologies, but I couldn’t quite catch your first sentence. I’m using a “raw” LPC1768 chip, unlike most others who are using the mbed LPC1768 which comes equipped with all other applications. Hence, based on the user manual, my “clock” will always come from the internal RC oscillator, unless if s/w switches it to the main oscillator.

Are you implying that system_LPC17xx.c is not the right code to start the main oscillator? If so, is there a sample software which does exactly this?

Once again, thank you for the verification.

8

There is nothing magic in the code or the startup.

From a hard reset the IRC (internal osc) is the clock source.

When the main oscillator is used, most of the time it is enabling the crystal oscillator and then using that to drive the PLL. This lets you run up to 120 MHz, something you can’t do any other way.

My assumption is the author of the code to do that wrote it with the idea that it is possible for the code to be called more than once, and to save time to check to see if the oscillator is running and the PLL already locked, and if so just return.

9

Hi again,

When I did my overall design, I have decided to use P1.27 (CLKOUT / USB_OVRCR) as the USB_OVRCR function (active low, pulled high). Hence each time I probe into this pin, I get a constant high voltage, i.e. I had to override the CLKOUT function in order to use the USB overcurrent function. Are there any other methods for me to check that my internal oscillator of my LPC1768 is really working?

I am still unable to get any oscillations on the oscilloscope for my 12MHz crystal, but based on past explanations, it is because I have yet to activate it by software. I hope this is the right explanation on why the main oscillator doesn’t show any oscillations yet?

Thank you.

10

If you got the “synchronized” the internal oscillator was working.

Until you turn on the crystal oscillator circuit (software required) you won’t see the 12 MHz wiggling. This is to save power when the part wakes up.

11

Hi,

I’m now able to communicate with my board, but when I downloaded the startup code to use my 12MHz crystal, I’m unable to get any oscillations from the oscilloscope.

The code I’m using is starter_code_21Oct2010 available from http://code.google.com/p/cortex-m3-tuto … 0&start=50. I downloaded it via FlashMagic and I didn’t get any errors. I ensured that my INT0 was still pressed before I released my RESET button (and subsequently released) to enter the bootloader before downloading the program.

I’m currently using a pair of 33pF capacitors for my 12Mhz crystal (from Abracon, through hole type, with a load cap of 16pF). Would using 22pF (as shown by the NGX website) help to solve this issue? Or could it simply be something gone wrong with the soldering?

12

Sigh, I have tried using a pair of 18pF capacitors, but all I get from the oscilloscope is still noise - similar to that when I used a pair of 33pF capacitors. I have also changed my 12MHz crystal before. The startup code, from my basic understanding of C programming, should start the main oscillator.

What can possibly go wrong?

13

Most likely software. You are debugging the hardest thing to do without JTAG tools or even with them. Basically if the software fails during the boot up stage you have very few tools for debugging.

What I use is wiggling an IO to see how far the software got.

In my case P2.10 is connected to an LED. So I put a routine called wiggle in and start binary searching to see where the problem is, by inserting calls to wiggle. If the LED does not flash the code never got there.

#define ABOUT_1_SECOND 400000

volatile int bit_bucket;

void wiggle(void) {

GPIO2_DIR = 1<<10;

while (1) {

GPIO2_CLR = 1 << 10;

for (bit_bucket=0; bit_bucket<ABOUT_1_SECOND; bit_bucket++);

GPIO2_SET = 1 << 10;

for (bit_bucket=0; bit_bucket<ABOUT_1_SECOND; bit_bucket++);

}

}

This is a good reason to buy a pre-tested PCB with a known good software tool to get started. Without that you are debugging your code, your setup (software and hardware), and your PCB.

14

Hi,

Thanks for the suggestion. I was away for quite some time and was unable to try out your suggestion then.

Anyway, I tried out the wiggle() method in a few areas, but all didn’t seem to work out. My last resort was to put it at the start of the Reset_Handler() method in startup_LPC17xx.c, but again, the LED didn’t blink. Here’s a snippet of the part that I added. (I used P2.0 as my LED)

////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////
#define ABOUT_1_SEC			  0x61A80		//equivalent to 400000 decimal
////////////////////////////////////////////////////////////////////////////////
volatile uint32_t bit_bucket;


void wiggle (void)
{
	LPC_GPIO2->FIODIR |= 1<<0;
	while (1) {
		LPC_GPIO2->FIOSET = (1<<0);
		for (bit_bucket=0; bit_bucket<ABOUT_1_SEC; bit_bucket++);
		LPC_GPIO2->FIOCLR = (1<<0);
		for (bit_bucket=0; bit_bucket<ABOUT_1_SEC; bit_bucket++);
	}

}
////////////////////////////////////////////////////////////////////////////////

void Reset_Handler(void)
{
	////////////////////////////////////////////////////////////////////////////////
	  wiggle();
	////////////////////////////////////////////////////////////////////////////////

I doubt there’s a problem when downloading the code via FlashMagic, coz when I probed into P0.2 and P0.3 (near the CPU side to ensure no broken link between the FT2232 chip and LPC1768 (CPU) chip), I see moving waveforms whenever a program is downloaded. Furthermore, FlashMagic did not present me with any errors. I thank you for your suggestion on getting a pre-tested PCB, but that option is unfortunately not possible for me as there is a limited budget for my project.

I am really at a loss as to what can go wrong since it seems that my hardware seems fine. On the s/w side, FlashMagic didn’t present any errors.

Thanks once again for all the useful info!

15

As Flash Magic seems to be happy the part is probably working.

You can verify that with most any terminal program, hold P2.10 low and reset the part

Send a ? from the PC (any baudrate - I usually use 19.2Kb)

The part should respond with Synchronized

If so, then the part is OK, and its your software setup that’s wrong (wrong memory map, no CRC value inserted at 0x14, though I thought Flash Magic inserted this). Flash Magic allows you to read the memory you just programmed, you might check that vs. what your software tool generated.

16

Yup, I don’t have a problem with the Synchronized part.

By the way, you mentioned about no CRC value inserted at 0x14 - how can I get more information on this? I am not aware that I need that CRC value at that particular location.

As for the memory map, can I presume that the memory map presented in the datasheet should tally with that written in the software code?

Thanks once again!

17

Information on the CRC is in the NXP user manuals, as I vaguely remember its on the first 32 vectors

You could also download our GCC tools, they are not setup for the 1768, but if you set it to 1756 it will compile and load code to get started (its a subset memory wise). To make them work for the 1768 would require some minor edits to the linker .ld file

http://www.coridium.us/files/setupC.exe

18

I decided to compare my generated hex file and the memory that I have just programmed. My generated hex file looks somewhat like this:

:102000000808001019210000000000000000000076
:10201000152100001521000015210000000000001E
:10202000000000000000000000000000152100007A
:1020300015210000000000001521000015210000FE
:1020400015210000152100001521000015210000B8
:1020500015210000152100001521000015210000A8
:102060001521000015210000152100001521000098
:102070001521000015210000152100001521000088
:102080001521000015210000152100001521000078
:102090001521000015210000152100001521000068
:1020A0001521000015210000152100001521000058
:1020B0001521000015210000152100001521000048
:1020C00015210000104B1A6842F080021A600E4B76
:1020D00080229A61803A0D4B01E01A6801321A6041
:1020E0000A4B0B4A19689142F7D9074A8021D161FE
:1020F000002201E01A6801321A60044B044A196890
:102100009142E4D8F6E700BF40C00920000000106B
:102110007F1A0600FEE70000684620F007018D46A2
:1021200001B5FFF7CFFF00F03FF8164B164A9A4271
:102130000AD0002303E01449595899500433114A36
:10214000124998188842F6D3114B124A9A420AD083
:10215000002303E00F495958995004330C4A0E49A3
:1021600098188842F6D30D4B02E0002243F8042B66
:102170000B4A9342F9D300F015F8BDE801408546BB
:10218000704700BF00000010842200000000001013
:102190000000001084220000000000100000001069
:1021A00004000010FEE70000334B2022C3F8A021FA
:1021B000314BD3F8A02112F0400FF9D00322C3F81D
:1021C00004212E4A0120C3F80C01AA21C3F884205F
:1021D0005522C3F88C10C3F88C20C3F88000C3F8D4
:1021E0008C10C3F88C20244BD3F8882012F0806F19
:1021F000F9D00322C3F88020A732C3F88C20553AC7
:10220000C3F88C201C4BD3F8882012F0407FF9D003
:102210002322C3F8A420AA2132320120C3F8AC1033
:10222000C3F8AC20C3F8A000C3F8AC10C3F8AC20CE
:10223000114BD3F8A82012F4806FF9D00322C3F811
:10224000A020A732C3F8AC20553AC3F8AC200A4B03
:10225000D3F8A82012F4407FF9D009490022C3F82E
:10226000A821C3F8AC21C3F8C410C3F8C82143F2B5
:102270003A021A60704700BF00C00F4063000500BB
:04228000DE872804C9
:0400000300002000D9
:00000001FF

Initially I couldn’t really tell what it was, but after looking at it carefully, I believe this is basically how it is partitioned:

AA BBBB CC [xx…xx] ??

AA refers to the number of bytes used (in hex) out of the 16 bytes starting from that particular memory location.

BBBB is the memory location in hexadecimal.

xx…xx refers to the content in the particular memory location.

I’m not so sure of the significance of CC and ?? though.

I checked the first line, i.e.

:102000000808001019210000000000000000000076

with that in memory location 0x0000 2000 (by using the read memory function in Flash Magic):

00002000 08080010192100000000000000000000 …!..

Every line from 0x0000 2000 to 0x0000 228F tallies with my main hex file - except the CC and ?? which I don’t quite understand it’s purpose.

As for the last two lines, in main hex file:

:0400000300002000D9

:00000001FF

I don’t quite know what it means too.

Hence, if what was generated and what was stored in memory tallies, could it be a fault somewhere in the makefile/linker script? Or can it still be an unknown h/w fault?

19

The hex file is Intel Hex Format, google to see what the format is.

You are missing the CRC word at 0xC, and that’s why the code is not starting up.

The tool chain you are using is not producing that, it may be an option in Flash Magic (did you select the proper device?)

In our GCC toolchain the code loader we use patches that location.

20

Thanks viskr!

It was indeed a software problem. I used another updated start-up code and the oscillations were finally showing. Thanks once again!