NUC120 port CM0 -> error compiling LPC11xx CM0 demo

[fjarnjak]

Hello,

I am trying to port ChibiOS to NUC120 series (specifically to NUC120LE3AN) because I got the development board from the manufacturer Nuvoton.
It is an ARM Cortex M0 core, so I have followed instructions and made subfolders from LPC11xx board/ os/port/ /demos/ and did some changes in path names, etc.
I also changed the linker script slightly to match NUC120 (CooCox IDE has support for NUC series of processors, so I used that for values since under CooCox IDE I did some bare metal code running on the board so linker script and vectors/startup file is OK and used LPC11 from ChibiOS). My port is started but it is far from finished....my first goal is to just compile and main() would have while(true) loop only. Then next step would be to deal with HAL for GPIO, etc.

Anyhow, problem I have on my system is in compilation. I have tried then to compile LPC11xx demo under command line and get the same problem. I am using latest Yagarto + Yagarto tools.

arm-none-eabi-gcc -c -mcpu=cortex-m0 -O2 -ggdb -fomit-frame-pointer -ffunction-s
ections -fdata-sections -Wall -Wextra -Wstrict-prototypes -Wa,-alms=../../os/por
ts/GCC/ARMCMx/LPC11xx/vectors.lst -DLPC1114 -D__NEWLIB__ -DTHUMB_PRESENT -mno-t
humb-interwork -DTHUMB_NO_INTERWORKING -MD -MP -MF .dep/vectors.o.d -mthumb -DTH
UMB -I . -I../../os/ports/GCC/ARMCMx -I../../os/ports/GCC/ARMCMx/LPC11xx -I../..
/os/kernel/include -I../../test -I../../os/hal/include -I../../os/hal/platforms/
LPC11xx -I../../boards/EA_LPCXPRESSO_BB_1114 -I../../os/various ../../os/ports/G
CC/ARMCMx/LPC11xx/vectors.c -o ../../os/ports/GCC/ARMCMx/LPC11xx/vectors.o
../../os/ports/GCC/ARMCMx/LPC11xx/vectors.c:174:1: fatal error: opening dependen
cy file .dep/vectors.o.d: No such file or directory
compilation terminated.
make: *** [../../os/ports/GCC/ARMCMx/LPC11xx/vectors.o] Error 1

Same is when I compile basically almost 100% same code for my NUC120 port.

Any ideas?

[Giovanni]

Hi,

From your log it seems you are still including LPC11xx and LPCXpresso paths in your makefile:

../../os/ports/GCC/ARMCMx/LPC11xx
../../os/hal/platforms/LPC11xx
../../boards/EA_LPCXPRESSO_BB_1114

The NUC120 is not a LPC11xx so you have several layers of problems:

1) You should create a NUC120 directory under ../../os/ports/GCC/ARMCMx/ and put there a NUC120-specific vectors, cmparams.h and port.mk. This step is very simple and will enable you to use the kernel (but not the HAL).

2) The LPC11xx HAL targets the LPC11xx peripherals so the drivers are not compatible with the NUC120, if you want to use the HAL and the various device drivers then you have at least implement specific HAL, PAL and Serial drivers. Basically you have to create a directory ./os/hal/platforms/NUC120 and put there your driver implementations (you may use the LPC/STM32 drivers as reference).

3) You have to create board files specific for your board under ./boards.

4) Your makefile must point to the above resources.

Giovanni

[fjarnjak]

For my port I did all those changes, and point to correct (new) directories for the port, etc.

So I tried compiling official LPC11 demo and if it works I would track down the error.
But it also fails - so output I have shown is for the LPC11 demo I have also tried compiling and I get that .dep vectors.o error.

[Giovanni]

Sorry, I missed the point.

It could be a problem with binutils and/or make. What GNU make version are you using? It should be version 3.81 or later. I tested using the make.exe included in YAGARTO, the one in MinGW and the one in Cygwin.

You can print the version using: make --version

You could also have multiple make.exe in your system, you should verify which one is picked up first in the PATH variable.

Giovanni

[fjarnjak]

You are right about that and I have been searching a bit on the web. It seems there is a problem running those ported compilers on Windows 7 64-bit which is a version which I use. Errors like below happen:

make all
AllocationBase 0x71560000, BaseAddress 0x71590000, RegionSize 0x4000, State 0x1000
C:\Yagarto\tools-20100703\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 0
AllocationBase 0x71560000, BaseAddress 0x71590000, RegionSize 0x4000, State 0x1000
C:\Yagarto\tools-20100703\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 0

Same thing also with AVR compilers on cyygwin, etc.

I have tried compiling on my other machine running Windows XP and it compiles with no issues.

So now I need to think what to do next...

[mabl]

Use Linux There are beautiful crosscompiler scripts. No, honestly - I will never understand why programmers use Windows with GNU tools. It's just so limited.

(Sorry, I could really not resist... - I mean no offense)

[fjarnjak]

At work we have to use Windows...due to other projects; embedded is just a small part of what I (only) do. At home life is simple

So now at work I have issues with WinAVR & Yagarto & etc each coming with their own set of binutils - so I need to add/remove things from the PATH not to use wrong ones, etc.

[Giovanni]

You could make a VW with 32bits Windows or Linux. I would also verify if some compatibility option is present in Win7 64bits.

Cygwin seems to be available compiled for 64bits, maybe you should try it too.

Giovanni

[fjarnjak]

I tried under Windows XP mode.

XP Mode doesn't have much software now at my PC so I:

Did a clean install of Yagarto tools and compiler.
Did a clean install (unpacked ChibiOS .zip) and went into demos/ARMCM0-LPC1114....

When I type make I get now:

C:\Eclipse-Projects\ChibiOS_2.2.7\demos\ARMCM0-LPC1114-LPCXPRESSO>make
C:\Program: C:\Program: No such file or directory
make: *** [../../os/ports/GCC/ARMCMx/crt0_v6m.o] Error 127

Again, this same ChibiOS .zip when ran on Windows XP machine works fine.

Windows7 are so frustrating for me I do lots of hardware work and I had to transition - before things worked like charm to access various devices and hardware I had to use....(XP), but now...

EDIT:

Works under Win XP Mode if you put Yagarto & Yagarto bin\ into PATH at the beginning only. I am not sure why it wouldn't work if it is at the end of the PATH setting, since I have no conflicting (other) make's or gcc, etc.

[Giovanni]

Try putting YAGARTO (or any other compiler) into paths without spaces, for example c:\yagarto. Spaces in paths are often troublesome.

Giovanni