I have installed Sourcery G++ Lite compiler in Keil IDE. Now I start to try to compile a simple Keil example (IOTest) for LPC1768 Cortex M3. The assembler language is different and I need to replace the file startup_lpc17xx.s, where can I find the correct version for Sourcery assembler ? Thanks
Stefano wrote: > I have installed Sourcery G++ Lite compiler in Keil IDE. > Now I start to try to compile a simple Keil example (IOTest) for LPC1768 > Cortex M3. > The assembler language is different and I need to replace the file > startup_lpc17xx.s, where can I find the correct version for Sourcery > assembler ? NXP provides a "CMSIS-Complient Driver Library" on it's web-site. Filename is lpc17xx.cmsis.driver.library.zip. There is startup-code for gcc in this package (search .../gcc/startup_LPC17xx.s). If have not worked with LPC17xx so far but please note that the startup-code in the Keil/ARM-examples often includes additional instructions in the assembler-setup (e.g. for PLL, clocks). But there is initialistaion-code for these settings available in system_LPC17xx.c in NXP's archive so porting should be easy.
OK, now I can compile without problem, but when link with ld.exe I have the following errors: startup_LPC17xx.s:132: undefined reference to `__cs3_stack' startup_LPC17xx.s:132: undefined reference to `__cs3_reset' startup_LPC17xx.s:132: undefined reference to `__start' Perhaps I should add some parameters ....... What can I do for solve this error ? Thanks
It seems that the used linker-script is incompatible with the startup-code. The undefined symbols get defined by the linker since there are instructions for this in the linker-script. The symbols are basically variables which hold memory-addresses (for example top of stack) and are later used during assembly of the startup-code. Did you use one of the linker-scripts which come with NXP's package (*_gnu.ld)?
OK, now I have in added the linker-scrpt file *.ld, the syntax is very complex and the example file is very long. Do you have a simple script-file for base configuration that can send to me. Thanks
Sorry. I do not have a simple ready-made linker-scripts which are compatible with the LPC17xx startup-code from NXP. I do not own a board with such a controller so I had no reason to create anything for it. But if the scripts and startup from NXP work just use them for now. You can read more about linker-scripts an the instructions in it in the binutils ld manual. The scripts from NXP seem to be based on the Codesourcery "standard" for linker-scripts and startup. IRC there is some information on this in the "getting-started" PDF-file included in CS G++ lite. Maybe this is useful for you: http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/arm_memcards/index.html#chanfat_stm32 It's for another controller also with Cortex-M3 core and it should be rather easy to port the linker-script and startup-code to LPC17xx. Decide yourself if it's "simple" enough Maybe someone else can jump in here and provide "simple" an tested examples for LPC17xx.
OK, now I am near able to work. I have an other question about CodeSourcery in Keil: - The "download code to flash memory" is no longer enabled, then I cannot program the target, is possible enable this function ? - The debugger function remain limited to 32K ? or is possible to debug code long more then 32k ? Thanks in advance
Stefano wrote: > OK, now I am near able to work. > I have an other question about CodeSourcery in Keil: The forum/support-request-form at keil.com might be a better place to ask questions on µVision. > - The "download code to flash memory" is no longer enabled, then I > cannot program the target, is possible enable this function ? Did you verify that Options for Target/Utilities is configured correctly for the used interface? Is an elf-file generated? Did you try with "generate hex-file" enabled in the project settings. The download function worked for me even when using the GNU cross-toolchain at least with older versions of the evaluation-software. I have not played with the latest version. > - The debugger function remain limited to 32K ? As far as I know: yes. The limiation of the debugger and simulator is not related to the used cross-compiler. > or is possible to debug code long more then 32k ? Keil/ARM sells unlimited versions and IRC also a less expensive package with 256kBytes limitation.