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.
Related
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.
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.
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.
I am currently implementing a simple tcp/ip server using an Atmel AT91SAM9260 evaluation board (ARM based micro-controller with several peripherals).
Some examples, given by Atmel include a uIP based web server but uIP cannot handle the throughput needed.
I found the same example based on version 1.1.1 (or slightly above) that was serving me just enough.
Recently I began to have problems with the stack and I couldn't find a port to the AT91SAM9260 with a newer version of lwIP. To build the project, I am using Eclipse+Yagarto+gcc as a development stack.
After just replacing the source code of the latest version 1.4.0 (available at http://download.savannah.gnu.org/releases/lwip/) into my project and attempting to fix all compile errors, I gave up.
The structure of the source code is very similar but apparently there's too many tweaks to be made.
Is there a specific guide on adapting the original source code to my stack? Wasn't the C++ code supposed to just compile on my stack?
At the wiki of LwIP http://lwip.wikia.com/wiki/Projects_that_use_lwIP I do see a reference to contributed ports of LwIP 1.3.0. That may be a starting point, at least for the ethernetif.c file.
To try and answer the second question: The C (not C++) is supposed to compile, but one still has to (at least):
setup lwipopts.h to determine how LwIP is to be used
provide ethernetif.h/ethernetif.c to tie your hardware to LwIP
setup sys_arch.h/sys_arch.c
I have the following problem:
I have a Matlab program in form of some set of *.m files. It is later compiled into executable and used. The problem is that occasionally the resulted executable just hangs and this behavior cannot be reproduced when debugging/running *.m files from IDE (even using the same input data).
To figure out what hapens I intended to:
compile (somehow) *.m files into C/C++
compile C/C++ as debug to get .exe and .pdb
And later when .exe hangs just 'attach' visual studio debugger to hanged .exe to check where it 'loops/waits'.
Unfortunaley Matlab Compiler (as I was told today) does not produce C/C++ code before creating executable. I was misleaded by -g option of mcc which according to the documenttion is supposed to do the following:
-g Generate Debugging Information
Include debugging symbol information for the C/C++ code generated by MATLAB Compiler.
It looks exacly like the thing I want to archive.
I would appreciate if someone could explain me that discapency or suggest how to archive what I am trying to do (if it can be done at all).
It is not possible to create a debuggable code in Matlab compiler, because the deployed code uses MCR. (Matlab virtual machine) .
See this question : Is there any way to debug compiled components using Matlab Debugger?
Since you don't have errors, but rather an infinite loop, the best solution in that case would be screen outputs, and hopefully you will trace the bug.