Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » DSDP - Real-Time Software Components (RTSC) » statically placed memory in a struct does not seem to work(configuration .c file generation problem)
statically placed memory in a struct does not seem to work [message #1419412] Mon, 08 September 2014 15:24 Go to next message
James Lockwood is currently offline James LockwoodFriend
Messages: 43
Registered: July 2009
Member
I have a module that I wrote that originally worked, and all I did was organize the Instance_State struct to contain another structure that was defined as tcb_t and named tcb.

Here is the relevant pieces of the .xdc file.
    struct TCB_t {
        volatile StackType_t *pxTopOfStack;      /*< Points to the location of the last item placed on the tasks stack.  THIS MUST BE THE FIRST MEMBER OF THE TCB STRUCT. */

//        xMPU_SETTINGS   xMPUSettings;          /*< The MPU settings are defined as part of the port layer.  THIS MUST BE THE SECOND MEMBER OF THE TCB STRUCT. */

        OSList.ListItem_t      xGenericListItem;   /*< The list that the state list item of a task is reference from denotes the state of that task (Ready, Blocked, Suspended ). */
        OSList.ListItem_t      xEventListItem;     /*< Used to reference a task from an event list. */
        UInt                 uxPriority;         /*< The priority of the task.  0 is the lowest priority. */
        StackType_t          pxStack[];            /*< Points to the start of the stack. */
        String               pcTaskName;/*< Descriptive name given to the task when created.  Facilitates debugging only. */ /*lint !e971 Unqualified char types are allowed for strings and single characters only. */

        StackType_t         *pxEndOfStack;       /*< Points to the end of the stack on architectures where the stack grows up from low memory. */

        UInt                 uxCriticalNesting;  /*< Holds the critical section nesting depth for ports that do not maintain their own count in the port layer. */

        UInt                 uxTCBNumber;        /*< Stores a number that increments each time a TCB is created.  It allows debuggers to determine when a task has been deleted and then recreated. */
        UInt                 uxTaskNumberTrace;       /*< Stores a number specifically for use by third party trace code. */

        UInt                 uxBasePriority;     /*< The priority last assigned to the task - used by the priority inheritance mechanism. */
        UInt                 uxMutexesHeld;

//        TaskHookFunction_t pxTaskTag;

        UInt32               ulRunTimeCounter;   /*< Stores the amount of time the task has spent in the Running state. */

//        #if ( configUSE_NEWLIB_REENTRANT == 1 )
            /* Allocate a Newlib reent structure that is specific to this task.
            Note Newlib support has been included by popular demand, but is not
            used by the FreeRTOS maintainers themselves.  FreeRTOS is not
            responsible for resulting newlib operation.  User must be familiar with
            newlib and must provide system-wide implementations of the necessary
            stubs. Be warned that (at the time of writing) the current newlib design
            implements a system-wide malloc() that must be provided with locks. */
//            struct  _reent xNewLib_reent;
//        #endif

    };



and in the internal: section
    struct Instance_State {
        TCB_t tcb;
    };



Upon compiling, now the generated code seems to not generate properly (I get compilation errors).

Here is a snippet of the configuration .c file that was generated that gives me the compiler error.

/* --> freeRTOS_mine_OSTask_Instance_State_0_tcb_pxStack__A */
__T1_freeRTOS_mine_OSTask_Instance_State__pxStack freeRTOS_mine_OSTask_Instance_State_0_tcb_pxStack__A[300];


__T1_freeRTOS_mine_OSTask_Instance_State__pxStack is undefined, so says the compiler.

It seems that the type for this array should have been:
__T1_freeRTOS_mine_OSTask_TCB_t__pxStack

The OSTask.h file that was created from my .xdc specification file generates this type for the tcb_t structure (contained within my Instance_State).

/* TCB_t */
typedef freeRTOS_mine_OSTask_StackType_t __T1_freeRTOS_mine_OSTask_TCB_t__pxStack;
typedef freeRTOS_mine_OSTask_StackType_t *__ARRAY1_freeRTOS_mine_OSTask_TCB_t__pxStack;
typedef __ARRAY1_freeRTOS_mine_OSTask_TCB_t__pxStack __TA_freeRTOS_mine_OSTask_TCB_t__pxStack;
struct freeRTOS_mine_OSTask_TCB_t {
    volatile freeRTOS_mine_OSTask_StackType_t *pxTopOfStack;
    freeRTOS_mine_OSList_ListItem_t xGenericListItem;
    freeRTOS_mine_OSList_ListItem_t xEventListItem;
    xdc_UInt uxPriority;
    __TA_freeRTOS_mine_OSTask_TCB_t__pxStack pxStack;
    xdc_String pcTaskName;
    freeRTOS_mine_OSTask_StackType_t *pxEndOfStack;
    xdc_UInt uxCriticalNesting;
    xdc_UInt uxTCBNumber;
    xdc_UInt uxTaskNumberTrace;
    xdc_UInt uxBasePriority;
    xdc_UInt uxMutexesHeld;
    xdc_UInt32 ulRunTimeCounter;
};



I have tried several versions of XDCTools, all the way up to 3.30.04.52.

[Updated on: Mon, 08 September 2014 15:26]

Report message to a moderator

Re: statically placed memory in a struct does not seem to work [message #1420281 is a reply to message #1419412] Tue, 09 September 2014 19:38 Go to previous messageGo to next message
Sasha Slijepcevic is currently offline Sasha SlijepcevicFriend
Messages: 115
Registered: July 2009
Senior Member
James,
I'll try to replicate the problem on a smaller example, but in the meantime can you try declaring pxStack to be a pointer? That's what you want it to be, right?
Re: statically placed memory in a struct does not seem to work [message #1420405 is a reply to message #1420281] Wed, 10 September 2014 00:23 Go to previous messageGo to next message
Sasha Slijepcevic is currently offline Sasha SlijepcevicFriend
Messages: 115
Registered: July 2009
Senior Member
I think if you just embed the elements of TCB_t into Instance_State, you'll get pxStack to be initialized as pointer to a statically allocated buffer. The size of the buffer will be determined at the config time by setting 'length'. Is there any reason why you can't do that? I'll keep looking at the original problem, but if you don't use TCB_t you could keep working while I look at the possible bug.
Re: statically placed memory in a struct does not seem to work [message #1420917 is a reply to message #1419412] Wed, 10 September 2014 17:20 Go to previous messageGo to next message
James Lockwood is currently offline James LockwoodFriend
Messages: 43
Registered: July 2009
Member
If I use a definition of pxStack[length], I would have to use pxStack.elem[i] C code to access/initialize it, which isn't so bad, although I have an extra field stored for the length that doesn't actually get used. Again, not a big deal.

Yes, embedding the elements of the TCB_t struct into the Instance_State struct works, but then there becomes a duplication management issue since TCB_t and the Instance_State must be identical for things to work. Not a show-stopper by any means, but that is still a work-around for the XDCTools issue I seem to have found.

For the time being, the work-around that I am using is to define the incorrectly named (undefined) symbol in my OSTask__epilogue.h file as follows:
#define __T1_freeRTOS_mine_OSTask_Instance_State__pxStack __T1_freeRTOS_mine_OSTask_TCB_t__pxStack
Re: statically placed memory in a struct does not seem to work [message #1420951 is a reply to message #1420917] Wed, 10 September 2014 18:32 Go to previous messageGo to next message
Sasha Slijepcevic is currently offline Sasha SlijepcevicFriend
Messages: 115
Registered: July 2009
Senior Member
I am not sure I understand your first sentence, but I think you are commenting on the difference between pxStack[length] and pxStack[] in the spec file. You don't need to use the form
pxStack[length]
to be able to assign to pxStack.length. It works for
pxStack[]
too, and you can access elements as pxStack[i]. I thought that's what you used originally.

Your workaround seems fine. If it works, then it means we just have a bug when generating type names, rather than having a problem with arrays inside structures inside instance states.

Re: statically placed memory in a struct does not seem to work [message #1421024 is a reply to message #1420951] Wed, 10 September 2014 21:05 Go to previous messageGo to next message
James Lockwood is currently offline James LockwoodFriend
Messages: 43
Registered: July 2009
Member
Yes, you are correct, I have been using

pxStack[]

in the .xdc file and
obj.tcb.pxStack.length = params.stackSize;
Memory.staticPlace(obj.tcb.pxStack, 4, null);

in my .xs file.

I didn't know that a call to Memory.staticPlace(....) wasn't necessary if data alignment wasn't needed, so that is helpful. Smile

I agree that the bug is only in generating the type name for the special case of an array that is declared in a struct that is used inside the Instance_State struct.

Re: statically placed memory in a struct does not seem to work [message #1568682 is a reply to message #1421024] Sat, 17 January 2015 03:11 Go to previous message
Sasha Slijepcevic is currently offline Sasha SlijepcevicFriend
Messages: 115
Registered: July 2009
Senior Member
There will be a fix for this problem in 3.30.06 and 3.31.00, sometimes in the next couple of weeks.
Previous Topic:XDCspec: variable length vectors ('[]', '[length]') generate undefined type names when nested
Next Topic:EMF/UML progress
Goto Forum:
  


Current Time: Thu Mar 28 16:02:53 GMT 2024

Powered by FUDForum. Page generated in 0.04062 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top