GCC to Rowley

nobody wrote on Thursday, July 13, 2006:

>We decided to merge from the commandline gcc to
>rowley 1.6 build 2. We disabled optimization until we
>get build 3. And we made a wiggler clone j-tag debugger.

>We stripped freertos to just a led blinker.

… and this works ok with the command line build?

>But we get crashes from rowley at the moment we step
>over a xtaskcreate line.

Can you step into xTaskCreate() and see where the crash is occurring?  This function attempts to allocate memory, maybe there is a byte alilgnment issue in the heap?

>And if we set a breakpoint after the init
>and just before it is in normal operation it wil work.
>But when it is in normal operation and we want to pause
>the session it also crashes.
>We would like to know if this is caused by freertos because it can’t
>be debugged like this. What possebilties are there to bedug the sources by
>j-tag and how.

Does the debugger work with projects that don’t use FreeRTOS.org?  It sounds like you are getting crashes before the kernel starts (xTaskCreate()), so I suspect it is not a FreeRTOS.org issue but a setup issue.  I have never had a problem like this with Rowley, but I have only used CrossWorks with J-Link and CrossConnect JTAG interfaces, not wigglers.

I think you need to step into xTaskCreate() to see where the crash occurrs.  This will provide a big clue as to what the problem is.

Are you calling main() in Supervisor mode?  There is a definition in Rowley to do this (look at the lwIP project file that uses CrossWorks in the FreeRTOS.org download).  Also are you setting up the Supervisor and IRQ mode stacks?  Again you can see how this is done from the other CrossWorks examples in the download.


rtel wrote on Thursday, July 13, 2006:

Reply is in message.

wacko_eddie wrote on Thursday, July 13, 2006:

The Ledblinker works fine in both the commandline gcc and rowley… But there was something not set correct.

We restarted with a new download of freertos 4.04
and one by one merging the components we use back in this. At that point we discovered that in the filesystem we use EFSL in debug mode it added debugsource wich caused the controller to reset.

Now we have this solved and we can run debug sessions.


wacko_eddie wrote on Thursday, July 13, 2006:

By any change does anyone know the memory simulation parameters for the arm simulator in rowley.

I want to do a execution trace with my source and this only possible with the arm simulator.

I’m working with the at91sam7x256.

nobody wrote on Thursday, July 13, 2006:

I’m not sure what you mean by memory simulation parameters.  Is this something you have to set up with regard to the memory map for the simulator?

I think the simulator in Rowley just simulates the ARM core.  It will not simulate the timer interrupt.  I may be wrong or they may be some way of scripting this, but it would make your trace a bit tricky if not.

wacko_eddie wrote on Friday, July 14, 2006:

What I read about the simulator it was able to trace in the source. To setup the simulator you need to give the path to a dll and a parameter as a string.

You can see this at the project properties->simulator