FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [October 2007 Threads] STR750_GCC stack allocationPosted by Jack Peacock on October 1, 2007 In looking at the ARM7/GCC in FreeRTOS 4.5.0 I'm having some trouble understanding the RAM allocations for the STR750 for stacks. __SVC_Stack_Size = 400 ; __IRQ_Stack_Size = 400 ; are obvious, as are the rest of the processor mode stacks. However, in the ARM7_LPC2368_Eclipse example the sizes of those two stacks are set to 100 instead of 400. Is there a reason for the change in size?
Also, in the STR750_GCC example, in the .ld file there is a _Minimum_Stack_Size = 0xC00 ; for the user stack, according to comments, to ensure a minimum size for "all stacks" at the top of RAM. What is this, and why doesn't it appear on the other GCC examples? Does this refer to the task stacks, and are the task stacks allocated from the heap or from this area? Jack Peacock
RE: STR750_GCC stack allocationPosted by Richard on October 2, 2007 > Is there a reason for the change in size?
Only that 400 is much more than required so wasteful. You can take a look at your stack usage high water mark and adjust as necessary.
>Also, in the STR750_GCC example, in the .ld file there is a >_Minimum_Stack_Size = 0xC00 ;
The linker files originate from Raisonance so are different just because they come from a different source. I think they put this line in purely so that a linker error will occur should there not be enough room at the top of RAM for at least this amount of stack space - although it seems not to match the sum of the individual stacks that are being allocated.
In the other linker files this link time guard is not used, so if you run out of RAM you will get stack corruption and probably a crash. Putting this line in will not prevent this happening of course, it just makes you more aware of the possibility prior to running the code.
Regards.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|