Hi all, my configuration is : Host PC : - linux x86 - Rowley CrossStudio for ARM - connected to eval board with wiggler eval board : - Atmel EB40A with AT91FR40008 I tried to run the demo GCC/ARM7_AT91FR40008_GCC and got a data access violation (dabt_handler is called) Doing single step I found out, that the the LR is loaded with 0xAAAAAAAA in the macro portRESTORE_CONTEXT and this value is set in the function pxPortInitializeStack. The next assembly line is "LDR        LR, [LR, #+60]" which leads to the access violation. What have I done wrong ? THX for your help Klaus Gromann

It sounds like your application might be starting in the wrong mode.  The application should start in supervisor mode then switch to system mode when the first task starts.  0xaaaaaaaa is the value the R14 of each task is initialised with, but it sounds like the value is in the supervisor R14 rather than the system mode R14. How did you generate your CrossStudio project?  The GCC/ARM7_AT91FR40008_GCC  demo uses command line GCC.  This requires a different startup file and linker script format to CrossStudio.  I suspect this is causing your problem.  There are also I think a couple of settings required in CrossStudio that you might not get using the GCC demo as a base. Also did you modify the interrupt handling at all from that included in the FreeRTOS download.  The interrupt handling routines have to be as per the download rather than as per the Atmel libraries. There is a FreeRTOS demo that uses CrossStudio but on a Philips device, rather than an Atmel  see the uIP demo.  You might be better off using this as your starting point rather than the command line GCC example.  Or at least looking at the startup and linker files as an example. Let me know how you get on, I may be able to assist futher. Regards.

If you can send me you project files (source code, CrossStudio project, linker files, etc. zip of entire directory) within the next hour or two I might be able to give them a try to see what is wrong.  After this I will be away from my office for a while. If you can then send the files to the email address on the FreeRTOS.org WEB site contacts page (r dot barry @ ….. ). Regards.

In conclusion – the problem was traced to the processor starting the application in the wrong mode. Regards.