Thomas Fernando wrote:
> When I try to do make or clean I get the :>>> "make.exe" clean> makefile:539: *** missing separator. Stop.
When I tried the same, I didn't get any error message. Moreover, I can't
find anything strange or dangerous near line 539 of the makefile.
However, I did the test in Linux and uesd a dummy command as replacement
for cs-rm, because I haven't installed the ARM tool set required to do
the build. But since the error seems to be a syntax error, there should
be no difference.
Are you sure not to have changed anything in the makefile? Which version
of make do you use? I use 3.81.
Thanks for replying Mr.Yalu.
I am using the make file from Version 20060606 of the WinARM
Just to check,I did "make" on one of my working projects and it works
Make -ver gives me GNU Make 3.80.
"Are you sure not to have changed anything in the makefile?"
Rechecked after just expanding the zip file,but the problem still
Are you using Windows or a Unix-like system? The Makefile contains
CR-LF line endings, and while they mostly work, they can sometimes
have subtle side effects (one I know for sure is that the sequence
backslash-carriage return-newline won't be accepted as a line
continuation under Unix).
Jörg Wunsch wrote:
> Are you sure the correct make.exe is called?
I tried one of my working projects after closing this one and it "makes"
clean and compiles without any problems.Would this verify your query ?
The comments in the makefile indicate that cs-make (CS G++) was used for
this project.I wonder if this is the issue ?Anyway I would not prefer to
switch the toolchain just for this reason.
Jörg Wunsch wrote:
> Just to make sure we are talking about the same file, line 539 of the> Makefile in question contains>>
> <TAB>$(CC) -c $$(ASFLAGS) $$< -o $$@
Yes its the same :
$(CC) -c $$(ASFLAGS) $$< -o $$@
Can we localize that the problem is this line only ? I mean in C if you
dont put a ';' the compiler shows another line as the problem sometimes.
I have attached the make file too.Thanks very much for your efforts.
Just a few remarks:
- IRC the problem has been just caused by the information strings
(Assembling...) and the quotes around them when using specific
combinations and versions of make, shell (msys-bash/zsh-Win32) and echo
(msys/cygwin/Windows-"native") on MS-Windows systems. Sorry, I can not
remember exactly what caused the problem but I have tried to fix it in
later versions of my "WinARM makefile-template".
- I'm now using Codesourcery's prebuild binaries (Codesourcery G++ lite
for ARM for MS Windows hosts) of the GNU cross-toolchain for my ARM
developments. Most of the newer example have not been tested with my old
WinARM packages any more. The old WinARM can be kept installed when
installing Codesourcery's package. There should be no side-effects since
different binary-prefixes are used (WinARM: arm-elf-, CS:
- Codesourcery (CS) uses the cs- prefix for the filenames of make and
rm. This seems to be good idea do avoid side-effects with other
"shell-utiltities" which are in the search-path on MS Windows systems
(i.e. from msys/MinGW as in from WinAVR|ARM\utils\bin) so I picked it
up and prepared the makefile and the batch-files/"shell-scripts" to use
the cs- prefix. cs-rm is just a "standard" GNU rm, cs-make is just a
GNU-make compilied for Win32 (Ver 3.81 for CS G++ lite 2009Q3). On
Unix/Unix-like systems just rm can be used in REMOVE_CMD as indicated in
the makefile and make can be used instead of cs-make.
Having this written: the example is a little older and has been tested
with CS G++ lite 2008Q3 before I published it on the web-server. I have
just tried to build with CS G++ lite 2009Q3 and make failed since the
dep-dir has not been created - I remember that I have fixed this too in
later projects for other targets so I quickly adapted my current "WinARM
makefile-template" for the project. At the momemnt I have no access to
my LPC213x/4x boards, so I could not test on the target but the build
works as expected.
Step-by-Step (MS Windows)
- Install Codesourcery G++ lite for ARM (the lite version is free)
- replace the Makefile in the project with the one attached to this
- double-click cs-make_clean_all.cmd (or type cs-make on shell/cmd)
- send feedback here
Since there is some attention for Unix/Linux/BSD users in this thread:
I integrated some "tricks" into later version of the makefile-template
to select between MS-Windows and Unix-like systems since the build on
Win32 is much faster if make uses the MS-shell instead of a
compatiblity-layer like msys-bash or zsh-Win32. I tried to keep the
makefile "multiplattform" but have not tested much on non-MS-OSes.
Feedback from "make clean all" tests with the attached makefile on
systems like Linux, BSD, OSX are welcome.
Hope this helps
Thanks Mr.Martin Thomas (MT) for the Makefile.
It is working with CodeSourcery (CS) G++ LITE.I have yet to add the SD
card ,but I have loaded the hex file using LPC21ISP and it sends me the
test string on the UART0.
In case it helps anyone,here is what was done :
1)Install G++Lite. ( Do not select the "add icons to desktop",else it
fills up your desktop with a whole lot of icons).
2)Download MT FATFs package from ,
3)Replace the makefile with the one added by MT,in this thread.
4)If you are using PN Prog from WinARM, add the cs-make_clean.cmd and
cs-make_program.cmd in the Tools Menu.These batch files are part of the
5)Modify the makefile to take care of your board and working directory
The above compiled and loaded hex file for me.
I was trying the given example code with LPC2148 and it works for all
the read Card routines that I tried.
1)When I move the same code to a LPC2138 board (same crystal freq) I was
unable to get the code to work.I get junk display on the UART terminal.
I am using the same .ld file and .S file for both the boards.
AFAIK it should work because LPC2148 is the same as LPC2138 except for
the USB function which I am not using in this project anyway.
2)The .ld file in any case is a modified LPC2368 file.
Thomas Fernando wrote:> I was trying the given example code with LPC2148 and it works for all> the read Card routines that I tried.> 1)When I move the same code to a LPC2138 board (same crystal freq) I was> unable to get the code to work.I get junk display on the UART terminal.> I am using the same .ld file and .S file for both the boards.> AFAIK it should work because LPC2148 is the same as LPC2138 except for> the USB function which I am not using in this project anyway.
Do you use a LPC2138 or LPC2138/01? Maybe the use of FIO (instead of
"legacy" GPIO) causes the issue.
> 2)The .ld file in any case is a modified LPC2368 file.>
> Wont these extra definitions for Ethernet and Battery RAMs create any> problems ?They seem to work fine for LPC2148,though.
IRC only the memory sections labeled ROM and RAM are used in the
output-section defintions. If so the URAM, ERAM and BRAM defintions are
redundant but should not cause problems.
Martin Thomas wrote:> Do you use a LPC2138 or LPC2138/01? Maybe the use of FIO (instead of> "legacy" GPIO) causes the issue.
I use LPC2138.
LPC2148 has U0FDR = (14 << 4) | 5; (enhanced UART),not available in
The blinking LEDs use FIO which was changed to GPIO.After correcting for
this the problem is resolved.
I think SPI1 also has some such issue (register or FIO),since the card
is not getting detected with LPC2138.Will check and post back.
Thanks for pointing the right direction.