What we need from you
The version of CrossWorks you are using
No, not just "CrossWorks for MSP430", or "CrossWorks for ARM", but the specific version of CrossWorks. You can get this information by choosing Help > About CrossWorks. Also provide the CPU and board support package versions, if applicable, which you can get from Tools > Show Installed Packages.
Describe exactly what you are doing and observing
We regularly get tickets saying something like, "If I do this, it doesn't work" which doesn't help a lot in diagnosing the problem.
Please describe exactly what it is you are doing and what you are observing.
If you are getting an error message, please tell us the exact error message you are seeing.
A simple application that we can compile
It's best to provide a complete application that demonstrates the fault with all the project properties set to the correct values for us to recompile and test. In CrossWorks 2, you can package up your project by right clicking the solution and choosing Create Package from Solution and mailing us the package file.
A concise set of instructions on how to replicate the fault
At least try. We can use our intelligence for most things but sometimes replication comes down to following a specific set of steps.
The hardware you are using, if hardware is required
Please indicate which evaluation board you are using and its revision. Yes, even its revision because some board revisions are very significant. Mention which JTAG interface you are using because sometimes this is important too.
If you are using your own board, please tell us that as well. If you are bringing up a new board, that would also be really useful to know.
Tell us the things that work as well as the things that don't
It can help immensely in diagnosing a problem if you can describe the things that are actually working for you (if any) as well as the things that aren't as it can quickly rule out possibilities that we don't need to consider. For example, if you've been running your project on a board successfully and you've switched to a new board and it doesn't, it would be really useful to know about the working board as that would most probably indicate problems with the board rather than the project.
Only one question per ticket
For the fastest possible response to a ticket, stick to just one question per ticket. This enables us to easily keep track of any unanswered issues, it also allows us to assign the ticket to the most suitable engineer to answer each question.
Comments
1 comment
Hi
(Questions marked with ------>)
We have a problem with code that loads and then uses a CAN Open Object Dictionary. It is code that has run perfectly before on another micro and compiled with an older version of the gcc compile. NONE of the code access any on chip hardware, so really it comes as a surprise that the code compiled for the new micro with the later version of the gcc compiler does not function.
Basically in the new micro the Object Dictionary (which is built in RAM) does not contain valid objects (either after the write or when they are read).
I have looked at the optimiser settings, but optimisation is at None. There are some compile directives in the new project (CrossStudio 2.3, Release 2.3.2. 2013053101.18474) , that are not in the old project. They are:
-ffunction-sections -fdata-sections -fno-common
------> I could see where to turn off -fno-common, but where do I turn off -ffunction-sections -fdata-sections? There seems to be no place in the project properties.
------> The old project compiled with "arm-unknown-elf", but the new project uses "arm-unknown-eabi". I tried to switch to using "arm-unknown-elf", but the Rowley libraries to link this version is not available (i.e. <libs of type ...\_v7em\_t\_le.a>. Can this be done? Is this a potential source of the problem?
------> Can you please give any other ideas where to look? Below are more details given:
Thanks you.
Previous working project info:
- Source code is in C and C++
- CrossStudio 1.7 Build 18 was used with the gcc compiler that came with it
- Code was compiled for ATSAM7A3
- Compile command line contains among other:
Compile:
........arm 1.7/gcc/bin/cc1 -fmessage-length=0 -mcpu=arm7tdmi -mthumb-interwork -mlittle-endian -mfpu=vfp -mfloat-abi=soft -nostdinc <some includes> -D__ARM_ARCH_4T__ -D__CROSSWORKS_ARM -D__TARGET_PROCESSOR=AT91SAM7A3 -DOSCILLATOR_CLOCK_FREQUENCY=18432000 -DBUILD_NUMBER=318 -D__ARM -D__FLASH_BUILD -DDEBUG -MD ARM Flash Debug/objects.d -MQ ARM Flash Debug/objects.o -quiet -gdwarf-2 -fno-builtin
Link:
arm 1.7/gcc/bin/ld -X -nostdlib -ereset_handler --omagic --fatal-warnings -EL -u_vectors -o <objects> <libs of type ...\_v4t\_a\_le\_mt.a>
-
Current problem project Info:
- Source is in C and C++
- CrossStudio 2.3, Release 2.3.2. 2013053101.18474
- Code is compiled for ATSAM4E
- Compile command line contains among other:
Compile:
........ARM 2.3/gcc/arm-unknown-eabi/bin/cc1" -fmessage-length=0 -mcpu=cortex-m4 -mthumb -mlittle-endian -mfpu=fpv4-sp-d16 -mfloat-abi=soft -nostdinc
<some includes> -D__ARM_ARCH_7EM__ -D__CROSSWORKS_ARM -D__CROSSWORKS_MAJOR_VERSION=2 -D__CROSSWORKS_MINOR_VERSION=3 -D__CROSSWORKS_REVISION=2 -D__TARGET_PROCESSOR=SAM4E8C -D__SAM4E8C__= -D__USE_CRYSTAL_OSCILLATOR__= -DNESTED_INTERRUPTS -DCTL_TASKING -DUSE_PROCESS_STACK -D__THUMB -D__FLASH_BUILD -DDEBUG -MD "THUMB Flash Debug/objects.d" -MQ "THUMB Flash Debug/objects.o" -quiet -gdwarf-2 -g2 -std=c99 -fno-dwarf2-cfi-asm -fno-builtin -ffunction-sections -fdata-sections -fno-common
Link:
ARM 2.3/gcc/arm-unknown-eabi/bin/ld" -X -ereset_handler --omagic -defsym=__do_debug_operation=__do_debug_operation_mempoll -u__do_debug_operation_mempoll -defsym=__vfprintf=__vfprintf_int -u__vfprintf_int -defsym=__vfscanf=__vfscanf_int -u__vfscanf_int --fatal-warnings -EL --gc-sections -u_vectors -o <objects> <libs of type ...\_v7em\_t\_le\_eabi.a>
End of mail.
Please sign in to leave a comment.