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 
distribution.
Just to check,I did "make" on one of my working projects and it works 
just fine.
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 
exists.

FYI :

I just copied only the Make from 20071113 which is Ver3.81 which still 
gives me the same problem !
Thanks

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).

Thanks Mr.Wunsch,
I am using Windows XP.

Any suggestions on how to divide and conquer ? I am not very familiar 
with makefiles.

Thomas Fernando wrote:
> Thanks Mr.Wunsch,
> I am using Windows XP.

Then it should not be a problem.

Are you sure the correct make.exe is called?

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.

No, the Makefile looks pretty much like a standard GNU Makefile
to me, e. g.:

1

$(foreach src, $(ASRCARM), $(eval $(call ASSEMBLE_ARM_TEMPLATE, $(src))))

These are GNU-specific extensions.

Just to make sure we are talking about the same file, line 539 of the
Makefile in question contains

1

<TAB>$(CC) -c $$(ASFLAGS) $$< -o $$@

Jörg Wunsch wrote:

> Just to make sure we are talking about the same file, line 539 of the
> Makefile in question contains
>
>

1

> <TAB>$(CC) -c $$(ASFLAGS) $$< -o $$@

2

>

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: 
arm-none-eabi-).

- 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 
message
- 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
Martin Thomas

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 ,
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/arm_memcards/index.html#chanfat_lpc2k_spi

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 
MT package.

5)Modify the makefile to take care of your board and working directory 
requirements.

The above compiled and loaded hex file for me.

Thomas Fernando

Hi ,

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.

1

MEMORY

2

{

3

  ROM (rx) : ORIGIN = 0x00000000, LENGTH = (512k-8k)  /* Flash: 512k - boot code */

4

  RAM (w) : ORIGIN = 0x40000000, LENGTH = (32k-32)  /* SRAM: 32k - IAP work */

5

  URAM (w) : ORIGIN = 0x7FD00000, LENGTH = (8k)    /* USB RAM: 8k */

6

  ERAM (w) : ORIGIN = 0x7FE00000, LENGTH = (16k)  /* Ethernet RAM: 16k */

7

  BRAM (w) : ORIGIN = 0xE0084000, LENGTH = (2k)    /* Battery RAM: 2k */

8

}

Wont these extra definitions for Ethernet and Battery RAMs create any 
problems ?They seem to work fine for LPC2148,though.

Thomas

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.
>

1

> MEMORY

2

> {

3

>   ROM (rx) : ORIGIN = 0x00000000, LENGTH = (512k-8k)  /* Flash: 512k -

4

> boot code */

5

>   RAM (w) : ORIGIN = 0x40000000, LENGTH = (32k-32)  /* SRAM: 32k - IAP

6

> work */

7

>   URAM (w) : ORIGIN = 0x7FD00000, LENGTH = (8k)    /* USB RAM: 8k */

8

>   ERAM (w) : ORIGIN = 0x7FE00000, LENGTH = (16k)  /* Ethernet RAM: 16k

9

> */

10

>   BRAM (w) : ORIGIN = 0xE0084000, LENGTH = (2k)    /* Battery RAM: 2k */

11

> }

12

>

> 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 
LPC2138.
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.

Thomas