I have a FreeRTOS code under KEIL compiler and all is OK. When I convert the same code to CooCox under GCC, where are only changes in asm code in port.c etc. It does not work. It is looping in debug in function xPortStartScheduler() where prvPortStartFirstTask() go to Svc_Handler and again to xPortStartScheduler() etc. I think that problem can be somewhere in vectors or startup file.
In CooCox I can't find heap and stack initialization instead of Keil sturtup.
Someone has an idea?
Problem was solved by rewriting vector table of imported CooCox sturtup where "vPortSVCHandler" was not defined. – Hw-dev Cz
I'm new to freeRTOS but you may find the startup file in CooCox by adding CMSIS boot component to the project. View->Repository and add CMSIS boot component to visualize the startup file in cmsis_boot/startup directory.
Related
Good morning,
I need to compile libgcc from scratch without deploying the ARM optimized version which is defined in ieee754-sf.s in the ARM back-end.
Does anyone knows how to configure GCC for excluding ieee754-sf.s ( in libgcc/config/arm ) to compile from scratch libgcc, in particular compiling vanilla floating-point soft-fp emulation which is in libgcc/spft-fp ?
Thanks
I dont know a configure command which does what you want. However if you want to do these modifications, you will need to modify lib1funcs.S to delete the references to the two files. you will need also to modify the t files (t-elf and t-arm at least) . gcc/config/arm/elf.h sould probably be modified too.
You can take a look at microblaze config directory. it shows a minimalist example
I am embarking on a project and would like to use EMIDE because it is OpenSource and the project budget is limited. I have some LPC1343 sample projects which are for Keil and the blinking led project works but I encounter a problem when I try to enable timer32 by calling:
enable_timer32(1);
The problem is that the program gets stuck. The only difference between Keil and EMIDE in the source code and header files is the start-up files. Keil start-up is in assembly and contains more IRQ vectors and the EMIDE is in C and states that it is a minimum set-up for Cortex m3. Since EMIDE is a GCC compiler I understand it needs a startup file in C. I cannot figure out how the start-up file needs to be amended or if this would solve the problem…
My question is as follows:
How can I modify the EMIDE startup file so that the program does not get stuck when I enable timer32?
Similar topics to this have been posted before but none have been fully resolved, for example here I get the same error when I use the Keil start-up in EMIDE.
Im working on Arduino Uno board recently im stuck with my code, i couldnt debug using print() in ArduinoIde.So i downloaded AtmelStudio 6.2 for debug purpose.
when i set the breakpoint and try to build .Im getting the warning
The breakpoint will not currently be hit. Unable to set requested breakpoint on target.The current selected deviceis unable to set breakpoints during runtime
please help me sort this issue
Following workarounds worked with the same problem using ATMega 168P on Atmel Studio 7 with Atmel-ICE.
1. Assembler
Insert the following assembler code where you want your breakpoint:
asm("break");
Please note, this is a really ugly solution and not suitable for all situations. It only works with DEBUGwire and makes your program stop in any case, even if no programmer is attached.
2. Create new project
Creating a new project at a different location helped as well. I copied all the required files to the new folder. The new location has a short path (C:\atmel\project...) and contains no spaces, no umlauts etc.
I had a similar problem, the difference was that I could only hit breakpoints in the original modules of my project (i.e. those already existent when I created the .cproj), any modules I added later wouldn't have the program stopped in breakpoints placed on them.
The solution (2) mentioned by #pafodie worked to solve this, but in the process I found a simpler way: just delete the .atsuo file. It will later be automatically recreated, and the problem disappears (at least until you add more modules). It seems AS6 caches something there that isn't updated when new files are added, or does it incorrectly.
I might've found a solution that works, for me at least! You need to disable compiler optimization. In Atmel Studio,
Hit Alt+F7 > ToolChain > Optimization {there are 2 Optimization
windows but only one fits the shoes} > Optimization level > None
I found it here, explained better than I did: https://www.microchip.com/webdoc/GUID-ECD8A826-B1DA-44FC-BE0B-5A53418A47BD/index.html?GUID-8FF26BD2-DBFF-48DD-91FB-8585D91A938D figure 5
If using external Makefile, make sure the -g (debug) flag is set in CFLAGS.
Otherwise, Atmel Studio would have no idea how the source files correspond to the compiled binary.
I am using the 2011 Q3 ARM GCC compiler with an ARM M0 platform. On my current application, if I do not use optimizations (compiling with -O0), my code is too large and doesn't fit. If I use any optimization (-O1, -O2, -O3, -Os), the SWITCH CASE statements do not work. I have validated the code inside this block is not getting executed as simple GPIO toggling operations are not coming through.
I read somewhere that any optimization from -O1 and above will have issues with goto code. However, I can't find the solution to this problem anywhere.
I also tried using the latest GCC ARM compiler, but my tools are not compatible with this release.
Any help on this matter is appreciated!
Try splitting your source code like so: the code that you don't want to optimize (eg. accesses to the memory mapped regions like GPIO) and the rest of it.
After you compile each source file with a different optimization level, you will get a working version with the "fragile" code.
Then, when you will debug the code, you will work with an object (.o) file and compile the rest.
In our project, we are building an ELF file and a partially linked file (PLF) which is converted to a proprietary format and loaded into memory after the ELF is loaded. We use Codewarrior to run and debug, which has been working just fine (the C++ source code is always available to step through when debugging).
I've recently made a change where some code and data are compiled into a different section in the PLF file (.init, which was previously empty). Now, when debugging, a majority of the files are available only in assembler. When I re-build, no longer using .init, we can step through C++ source code again.
Does anyone know why this would be the case?
why this would be the case
One reason could be that codewarrior is not expecting to find code in .init section.
You are unlikely to get a good answer here. Try codewarrior support forums.
I got this working by switching the order of the sections using the linker command file (.lcf) so that the .init section comes second after .text. I guess as Employed Russian suggests, CodeWarrior is surprised by having code in .init and craps out. Changing the order of the sections seems to have no ill effects and now debugging works as expected again.