Anglia Electronics kindly sent me an Eclipse version of the STM32demo project. It includes a custom makefile, so it doesn't use any outside resource such as Solaris to create the makefile. I am trying to create my own project to emulate this with good success so far. In my project I am using Solaris to create the makefile for me, so I can add or delete modules at will without having to modify the makefile each time. However, when I compile the Anglia version of the project the Eclipse disassembly window shows each line of source code, followed by the assembler code generated. When I step through the code the source window and the disassembly window track logically. My project does not include the relevant source code line in the disassembly. Furthermore, if I step through the code the 'cursor' in the source code window follows approximately where it should be, but may jump backwards or forward several lines each time I step. Examining my disassemby explains the jumping, since the code is not totally logical. For example, if I have a sequence of lines setting variables to specific values the code is likely to load each value in turn to different r registers, then write each r register in turn to the relevant memory address. The same code in the Anglia version would load the first value into an r register, then copy it to the relevant memory address, then proceed to the next variable. Can anyone help in identifying how to configure the compiler to create logical code, and embed source code into the disassembly listing? I suspect the difference must be within the makefile, since this invokes gcc, but all my switches are the same as those in the original. From searching the web I suspect I need to invoke objdump somewhere. Regards
The reason for the reordering of the code is the compiler optimization. You are probably using -O2 or -O3, try a lower optimization level (-O1) or disable optimization completely (-O0) if the reordering bothers you and you can live with (slightly) slower/bigger code. You can generate an assembler listing with embedded C source code by running objdump with the options -dS. Not sure if that's the way to do it so that Eclipse understands it, but can't you just compare your Makefile to the Anglia Makefile to see how it calls gcc/objdump/...?
Hi rousea , I don't have an answer to you question, but is it possible for you to upload the project template from anglia? At the moment I'm evaluating Crossworks, but i'm not very happy with it. My Problem is I can't get Eclipse working for me :(.I would be happy to see some samples for organizing a project with eclipse Regards Michael
Hi Thanks for the reply. Both my project and the original Anglia project invoke the gcc compile with the flag -Os, so that can't explain the difference between the two resultant disassembly listings. I have attached the Anglia makefile in case you can decipher how it is using objdump. In Eclipse I have configured Project\Properties\C/C++ Build\Settings\Tool Settings to add the required flags to the Solaris compiler and linker. After compiler each project I have looked in the console window to see the command strings invoked and confirmed that the gcc flags are virtually the same. There are differences, but they relate to the different folder structure I use to store the .c and .h modules. I originally had the text "objcopy -O srec Mega_Link.elf Mega_Link.s19" in the Build Steps\Post Build Steps\Command window (Mega_Link being the name of my project). I tried changing this to "objcopy -O srec Mega_Link.elf Mega_Link.s19; objdump -dS Mega_Link.elf". During compilation streams of disassembly code scroll through the console window, but when it has finished and I launch the project, the contents of the Disassembly window are the same as before. I am obviously not using objdump correctly, Can you give any further ideas? Regards
I do not fully understand what you mean with "Solaris compiler and linker" but did you double-check that -g is in your "Tool Settings" command-line options?
Thanks for your comments. I myself am very confused about the build variant I am using. It took an exceptionally long time for me to get the IDE, compiler and debugger to work. I initially downloaded Eclipse Gannymede, but was unable to compile of debug the project. I followed instructions on numerous websites to try to fix this. As far as I remember I downloaded Zylin, Cygwin, gdb, CodeSourcery and Solaris. Some of these are build variants of gcc, some are add-ons for Eclipse. Eventually I got a combination that works. Ideally I would like to start again with a build that just includes the add-ons I need to do the job, but I am afraid that I will have difficulty unless someone can give be concise instructions of how to build Eclipse and gcc to develop and debug software for an Arm Cortex processor. The console window shows that the commands used to build each module are typically: gcc -nostdinc -DLCD_ILI9320 -DSTM32F103x8B -IC:/Software/Mega_Link/Mega_Link/Include -Os -g3 -Wall -c -mthumb -march=armv7-m -ffunction-sections -fdata-sections -Wno-pointer-sign -o Source\usb_endp.o ..\Source\usb_endp.c and the linker command is: gcc -nostartfiles -LC:\cygwin\lib\gcc\arm-eabi\4.2.3\thumb -mthumb -march=armv7-m -Tstm32rom.ld -Wl,-Map=obj\Mega_Link.map,-cref,--gc-sections -ggdb -oMega_Link.elf usb\src\usb_regs.o .... Source\IO.o You will see that the compiler includes -g3 and -Os, which I believe together define the output format. However, I have tried all combinations of these flags without success. The above setting produce code that works, but is not easy to follow against the source. Regards
No out-of-the-box solution but some suggestions/remarks: The command lines just show gcc, the CS cross-toolchain uses the prefix arm-non-eabi so arm-none-eabi-gcc should be there. Are there any symbolic- or hard-links set? But maybe you are still using the toolchain from the Anglia package, IRC they do not use a prefix. I usually use -gdwarf-2 but have to admit that I have never played with the -g options. So you may try -gdwarf-2 or just -g instead of -g3 and -ggdb. The optimization setting (-O) should not have any influence on the generation for debug-information. You should not use or need to use absolute pathes like ...\thumb when using the frontend (arm-none-eabi-gcc) for linking and a rahter new build of the toolchain. Remove the options -ffunction-sections, -fdata-sections and --gc-sections for now; can be added later once everything else is running. I still not not get what you mean with "Solaris". If it's the OS from SUN I don't see how this is related to the problem. "cross-gdb" is included in the CS package (arm-none-eabi-gdb), no extra download needed. The CDT GDB hardware debugging plugin can be used instead of the Zylin plugin. But in the OpenOCD mailing-list there have been reports about problems with the gdb in current version of CS G++ lite for ARM. Not sure, please search the OpenOCD mailing-list archive. Like M.Bubestinger I'm interested in the package that has been sent from Anglia. Please ask them for permission so you may attach it to a message. (S. "ntfreak" O.: do you read?)
Thanks for your response. I have asked Anglia for permission to forward you their project. I obviously can't respond to you until I have their reply and I have had time to digest all your comments. Since it is now Friday evening it will take a few days, but I will reply. Regards
Hi I have attached the Eclipse configuration sent by Anglia. However, I must have changed something on my system, because it now fails at the end of compilation with the message 'cannot open map file obj\stm32demo.map' I am now getting extremely frustrated with Eclipse. I want to use it as a tool for developing a project to run on embedded hardware, but I am spending more time trying to fix the tool than I am spending developing the project! I sincerely hope that someone somewhere can come up with a foolproof method of building Eclipse with all the necessary plug-ins so it can be used to develop projects running on ARM Cortex targets. Incidentally, at some stage I stumbled across Solaris as a tool for constructing the compilation. The attachment includes some screeshots that show the options presented for the compiler and linker. I have not found any other means of easily configuring the project properties.
I don't think the "Solaris C Compiler support" is the best solution. There is a arm-gcc plugin for Eclipse available at sf.net but since I'm using Eclipse with a self-made makefile I can not provide additional information on this plugin. I suggest that you use a makefile too. There are tutorials from Jim Lynch (google for them) which explain the setup with an external makefile. Once you have the building working you can turn to the debugging with a gdb-server (i.e. OpenOCD). Another option might be to buy a commercial solution. AFIAK Codesourcery offers Eclipse-support in the "non-lite" versions for CS G++ for ARM. Sorry, I can not offer a foolproof solution. I'm using Eclipse as Editor and Debugger (with OpenOCD) but did not have the time to write a "guide". Anyway my setup for building (not debugging) is very similar to the one described by Jim Lynch.
Martin I am extremely appreciative of the effort you have taken to give a comprehensive response, and would like to thank you for it. I have found the articles published by Jim Lynch. In fact I had seen them some time ago, but I had discounted them because they don't encompass ARM Cortex. They were written around 2005, before the release of Cortex. The same applies to YAGARTO, but their website specifically states that it does not cover Cortex. I assume from this that incorporating Cortex is not a trivial task. I guess my objective of implementing a variant of Eclipse that automatically creates the makefile should not be regarded as essential. However, the work I have done to date with the Solaris add-on proves to be a great benefit where new modules are added as the project evolves. It saves time when I don't have to keep modifying the makefile to accommodate the changes. The implementation of Eclipse that I now have is compatible with Cortex and allows me to download a debug the software on my target. However, the shortcomings are: 1) It does not step through code logically, and doesn't embed the C source within the disassembler 2) It doesn't include library functions (e.g. ctype.h) 3) After all my abortive efforts I don't know how I eventually built it, so can't replicate it on another computer. Regards
Watch this topic
Disable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.