Who's got a linker script for the LPC1768?

Development Boards MicroMod
1

I’m lost! Can’t seem to find one. I’m modifying existing ones (LPC17xx) based on the memory in the 1768 and I can’t get it to vector off and run code! I spent years working with the LPC2124 and LPC2138 and never had this problem! I developed entire UAV autopilots around these chips. In hindsight, I guess I had a good linker to start with because I never had to learn this part.

Or reading on this stuff? I’m willing to RTFM.

2

You could start with our tools for the LPC1751/1756 which are a proper subset memorywise for the LPC1768. They are build on the Yagarto GCC toolbase, and are preconfigured for our boards, including those sold here at SparFun.

http://www.coridiumcorp.com/files/setupC.exe

Use the settings for the SuperPRO which is a 1756, and in the com control settings select Manual as you’ll need to hold P2.10 low during reset.

Once you get a working base you can go in and start changing linker scripts and break things.

3

Thanks a lot. I was able to build and load Superpro, and it vectors off and runs. Now I just need to dig around under the hood. I tried just cutting and pasting the *.ld file into the project I have going in Eclipse, but of course it’s not that easy. Thanks!

4

Thanks for the help viskr. The problem is that I don’t know enough about this stuff to be able to tell what’s going on under the hood. I’ve been trying to adapt your linker script to work with other projects in eclipse/codesourcery/etc, but I’m having the same problem of getting stuck in ISP.

I also want you to know that there is an issue with coredium not fully uninstalling itself. I had to hit a system restore point in order to reinstall it and get the same functionality ~ probably something to do with the registry,

5

If you mean “getting stuck in ISP” that your code doesn’t start up. Then something in your initialization code is not correct.

I’m actually fighting the same battle today as we bring up an LPC1114 based design. What you’ll probably end up having to do is put a small routine in your code to locate the problem. I usually wiggle an IO line (one connected to an LED if available). Put it at the start of the code and move it through til it doesn’t wiggle anymore, and it will point you in the direction of the problem.

Thanks for the uninstall feedback, its not in the registry, we don’t use the registry. What it probably is the .INI file which use to be in the Program Files area, but is now by Microsoft convention in the %appdata% directory, and we haven’t been removing that during uninstall.

6

Thanks again man. I uninstalled the program because at one time I had 4 different versions of the gcc chain in my path, and I was trying to streamline and remove concern for error.

Also the hex files were stored in that area which you were talking about and that gave me great grief when trying to get to them from Flash Magic to try and load it that way. I couldn’t cd to it, but I was able to change permissions on the folder and give Flash Magic the full path.

Anyway, I’m blinking from a program I BUILT! I did this by using an LPC1766 example:

http://embeddedfreak.wordpress.com/2009 … eripheral/

in eclipse:

-changing the PATH in properties/C C++ build/Environment to match my codesourcery file

  • changing the make command in properties/C C++ build to cs-make

and using this makefile:

NAME=test
SRCS=main.c startup_LPC1766.c
OBJS=$(SRCS:.c=.o)

default: $(NAME).elf $(NAME).hex

%.o:%.c
	arm-none-eabi-gcc -O2 -ffunction-sections -fdata-sections -g3 -Wall -c -mcpu=cortex-m3 -mthumb -omain.o main.c

$(NAME).elf:$(OBJS)
	arm-none-eabi-gcc -O2 -ffunction-sections -fdata-sections -g3 -Wall -c -mcpu=cortex-m3 -mthumb -ostartup_LPC1766.o startup_LPC1766.c

%.hex:%.elf
	arm-none-eabi-gcc -Wl,–gc-sections -Wl,-Map,LPC1766_Systick_Interrupt.map -Wl,-T,LPC1766.ld -oLPC1766_Systick_Interrupt.elf  main.o startup_LPC1766.o

clean:
	rm -f $(OBJS) $(NAME).elf $(NAME).hex