EmbeddedRelated.com
Forums
The 2024 Embedded Online Conference

FREERTOS problem on gcc and LPC2138

Started by rseku October 21, 2005
Hello Richard!

Thank You very much for your time so far!
But so far I hardly understand meaning of startup procedure before main().

Finally I figured out there is a .hzp project file, You mean.
First of all,the common configuration contain target name as LPC2124.
Changing target in Thumb Debug configuration to LPC2138, will probably
cause the common configuration don't apply any more.
Am I correct?

Secondly: for unknown reason my new configuration button is greyed out.
Thirdly: Common configuration is not accessible the normal way (
through windows)

robert

FreeRTOS Info wrote:
>>PS: Oh my God! I think I've been bumping my head against the desk all
>>day for the same exact problem! > The scheduler code always runs in Supervisor mode (the tasks in System
> mode). The processor must therefore be in Supervisor mode when
> vTaskStartScheduler() is called, otherwise the code fragment previously
> posted will pop the registers into the wrong place.
>
> The startup code for the demo applications ensures the processor is in
> Supervisor mode when main() is called. This is why I try and emphasis in
> the docs that the best way of creating a new application is to start with
> and then modify the provided code/project. This way all the compiler
> options and the startup code are automatically correct and you will not get
> any problems.
>
> I am thinking about updating the code to ensure a switch into Supervisor
> mode actually in the scheduler code immediately prior to the first task
> being started. While it would prevent this problem from occurring it is
> still really encouraged to use the provided startup code anyway, as it also
> configures all the stacks as necessary.
>
> Regards,
> Richard. > http://www.FreeRTOS.org >
>
> Yahoo! Groups Links >
>




An Engineer's Guide to the LPC2100 Series

Richard

I forgot to ask: should I add Loader.exe to the project?

robert
FreeRTOS Info wrote:

>>PS: Oh my God! I think I've been bumping my head against the desk all
>>day for the same exact problem! > The scheduler code always runs in Supervisor mode (the tasks in System
> mode). The processor must therefore be in Supervisor mode when
> vTaskStartScheduler() is called, otherwise the code fragment previously
> posted will pop the registers into the wrong place.
>
> The startup code for the demo applications ensures the processor is in
> Supervisor mode when main() is called. This is why I try and emphasis in
> the docs that the best way of creating a new application is to start with
> and then modify the provided code/project. This way all the compiler
> options and the startup code are automatically correct and you will not get
> any problems.
>
> I am thinking about updating the code to ensure a switch into Supervisor
> mode actually in the scheduler code immediately prior to the first task
> being started. While it would prevent this problem from occurring it is
> still really encouraged to use the provided startup code anyway, as it also
> configures all the stacks as necessary.
>
> Regards,
> Richard. > http://www.FreeRTOS.org >
>
> Yahoo! Groups Links >
>




There are two separate threads here, one about startup code ensuring
Supervisor mode and the other about creating an ARM build using CrossWorks.

> But so far I hardly understand meaning of startup procedure before main().

The startup code being the code that executes to setup the C environment,
then calls main(). In this case it is called crt0.s, and is included in the
sample FreeRTOS project under the System Files folder (in the CrossWorks
Project Explorer window).

This code has to ensure the processor is in Supervisor mode when main() is
called. CrossWorks makes this really easy - all you have to do is define
SUPERVISOR_START as a preprocessor macro. If you look under menu option
Project->Properties->Preprocessor->Preprocessor Definitions you should see
how this is done. > Finally I figured out there is a .hzp project file, You mean.
> First of all,the common configuration contain target name as LPC2124.
> Changing target in Thumb Debug configuration to LPC2138, will probably
> cause the common configuration don't apply any more.
> Am I correct?
>
> Secondly: for unknown reason my new configuration button is greyed out.
> Thirdly: Common configuration is not accessible the normal way (
> through windows)

If you are new to CrossWorks I suggest looking over the relevant manual
pages on Solutions, projects and configurations:
http://www.rowley.co.uk/documentation/arm/arm_ide_tutorial.htm Regards,
Richard. http://www.FreeRTOS.org


I traced the problem further and I found, that the data_abort appears in
call to static void vErrorChecks( void *pvParameters );
first command : mov r12,sp where SP is 0x40002408 calls exception.
I also checked, that code before that mode was in supervisor mode,
and now is in user mode, as You mentioned Richard.

I would like also to stress that only change I made was Project
properties regarding different processor type, and I removed
prvHardwareSetup function, because it's implemented in startup function
LPC210x_startup.s ( M = 4,P = 2,MAM enabled (use_MAM),VPBDIV =1 Regards
robert

Guillermo Prandi wrote:
> --- In lpc2000@lpc2..., "FreeRTOS Info" <nospam@F...> wrote:
>
>>>I wonder... what does this instruction aim for?:
>>>
>>>asm volatile ( "LDR LR, [LR, #+60]" );
>>>
>>>What is LR+60 pointing to? Why 60? Why not 56 or 64?
>>
>>The stack frame is always the same, and this is the offset to the
>
> return
>
>>address once the context has been restored.
>>
>>Regards,
>>Richard.
>>
>>
>>http://www.FreeRTOS.org
> > Oh, I see... 60 = 15 (registers) x 4 (bytes per register).
>
> Thanks, Richard. >
>
> Yahoo! Groups Links >
>




> I traced the problem further and I found, that the data_abort appears in
> call to static void vErrorChecks( void *pvParameters );
> first command : mov r12,sp where SP is 0x40002408 calls exception.
> I also checked, that code before that mode was in supervisor mode,
> and now is in user mode, as You mentioned Richard.
>

This is the first task to execute as it is the highest priority. So it is
data aborting on effectively the first instruction. Maybe the ARM/THUMB
mode of the processor is not matching the code.

I could take a look at your project if you like. If so zip up the entire
FreeRTOS directory, then send it to the address from the FreeRTOS.org WEB
site contacts page (r _dot_ barry -at- freertos +dot+ org ).

Regards,
Richard. http://www.FreeRTOS.org


I have the latest (I think version of FreeRTOS ) but there is neither
system folder in this example nor crt0.s.
In fact crt0.s is within the projects but it's orgin is within
CROSSWORKS directory, not FreeRTOS. as in opposition to other FreeRTOS
projects.
And I repeat, I just wanted to try uIP example with other chip. I didn't
add my code yet.(so nothing is changed).

robert

FreeRTOS Info wrote:

> There are two separate threads here, one about startup code ensuring
> Supervisor mode and the other about creating an ARM build using CrossWorks. >>But so far I hardly understand meaning of startup procedure before main(). > The startup code being the code that executes to setup the C environment,
> then calls main(). In this case it is called crt0.s, and is included in the
> sample FreeRTOS project under the System Files folder (in the CrossWorks
> Project Explorer window).
>
> This code has to ensure the processor is in Supervisor mode when main() is
> called. CrossWorks makes this really easy - all you have to do is define
> SUPERVISOR_START as a preprocessor macro. If you look under menu option
> Project->Properties->Preprocessor->Preprocessor Definitions you should see
> how this is done. >
>>Finally I figured out there is a .hzp project file, You mean.
>>First of all,the common configuration contain target name as LPC2124.
>>Changing target in Thumb Debug configuration to LPC2138, will probably
>>cause the common configuration don't apply any more.
>>Am I correct?
>>
>>Secondly: for unknown reason my new configuration button is greyed out.
>>Thirdly: Common configuration is not accessible the normal way (
>>through windows) > If you are new to CrossWorks I suggest looking over the relevant manual
> pages on Solutions, projects and configurations:
> http://www.rowley.co.uk/documentation/arm/arm_ide_tutorial.htm > Regards,
> Richard. > http://www.FreeRTOS.org > Yahoo! Groups Links >
>




> I have the latest (I think version of FreeRTOS ) but there is neither
> system folder in this example nor crt0.s.

? Either you are looking in the wrong place or this is not a project from
the download. As per my post, I'm talking about a folder shown in the
project explorer within the CrossWorks IDE, not a directory within the
source tree. Do you have the project explorer window open? Select "project
explorer" from the View menu in the IDE if not.

If you could send your project as per my previous request then I should be
able to find the problem. In the mean time I think we should continue this
discussion on the FreeRTOS support forum as the thread is getting quite long
and is not likely to be of general interest to others on this group.

Support forum can be found here:
http://sourceforge.net/forum/forum.php?forum_id82005

Regards,
Richard. http://www.FreeRTOS.org


Richard, I wouldn't mind hearing about Robert's problem and his
resolution.

Guille

--- In lpc2000@lpc2..., "FreeRTOS Info" <nospam@F...> wrote:
>
> > I have the latest (I think version of FreeRTOS ) but there is
neither
> > system folder in this example nor crt0.s.
>
> ? Either you are looking in the wrong place or this is not a
project from
> the download. As per my post, I'm talking about a folder shown in
the
> project explorer within the CrossWorks IDE, not a directory within
the
> source tree. Do you have the project explorer window open?
Select "project
> explorer" from the View menu in the IDE if not.
>
> If you could send your project as per my previous request then I
should be
> able to find the problem. In the mean time I think we should
continue this
> discussion on the FreeRTOS support forum as the thread is getting
quite long
> and is not likely to be of general interest to others on this group.
>
> Support forum can be found here:
> http://sourceforge.net/forum/forum.php?forum_id82005
>
> Regards,
> Richard. > http://www.FreeRTOS.org
>




> Richard, I wouldn't mind hearing about Robert's problem and his
> resolution.
>
> Guille

I will post back with the resolution. Currently I am having problem
simulating the code for some reason, although i did notice the offending
file had been changed to ARM mode while the rest remains unmodified as
THUMB. Until I get my simulator working correctly I'm not sure of the
effect.

Regards,
Richard. http://www.FreeRTOS.org


Thanks
I just sent the FreeRTOS directory to Richard.
I will post to this group if we find anything.
I noticed there was no port to LPC213x group yet, I might take an
example from.

robert

Guillermo Prandi wrote:
> Richard, I wouldn't mind hearing about Robert's problem and his
> resolution.
>
> Guille
>
> --- In lpc2000@lpc2..., "FreeRTOS Info" <nospam@F...> wrote:
>
>>>I have the latest (I think version of FreeRTOS ) but there is
>
> neither
>
>>>system folder in this example nor crt0.s.
>>
>>? Either you are looking in the wrong place or this is not a
>
> project from
>
>>the download. As per my post, I'm talking about a folder shown in
>
> the
>
>>project explorer within the CrossWorks IDE, not a directory within
>
> the
>
>>source tree. Do you have the project explorer window open?
>
> Select "project
>
>>explorer" from the View menu in the IDE if not.
>>
>>If you could send your project as per my previous request then I
>
> should be
>
>>able to find the problem. In the mean time I think we should
>
> continue this
>
>>discussion on the FreeRTOS support forum as the thread is getting
>
> quite long
>
>>and is not likely to be of general interest to others on this group.
>>
>>Support forum can be found here:
>>http://sourceforge.net/forum/forum.php?forum_id82005
>>
>>Regards,
>>Richard.
>>
>>
>>http://www.FreeRTOS.org
> >
> Yahoo! Groups Links >
>





The 2024 Embedded Online Conference