PIC18 Memory corruption during context restor

nobody wrote on Tuesday, April 24, 2007:

Hey Guys!

Currently I’m trying to get FreeRTOS working under MPLAB 7.52 using
C18 v3.10 on a PIC18F4620.

Despite a few compiler warnings, and a few extra typecasts, all is working weel, exept for 1 really big problem (in my eyes).

I’m pretty new to RTOS, but during my testing, I found a disturbing issue.
The RTOS documentation says for the portSAVE_CONETXT macro

* The compiler uses some locations at the bottom of the memory for temporary
* storage during math and other computations.  This is especially true if
* 32bit data types are utilised (as they are by the scheduler).  The .tmpdata
* and MATH_DATA sections have to be stored in there entirety as part of a task
* context.  This macro stores from data address 0x00 to
* sysCOMPILER_MANAGED_MEMORY_SIZE.  This is sufficient for the demo
* applications but you should check the map file for your project to ensure
* this is sufficient for your needs.  It is not clear whether this size is
* fixed for all compilations or has the potential to be program specific.

Well, this gave me a little headache, because when I execute the code, some variables declared in port.c are overwritten by crap during the first portRESTORE_CONTEXT.
I’m not very good in assembler, but when I look at my map file, I don’t think
the MATH_DATA and .tmpdata sections are stored at the bottom (0x00):

Snippet from map file:
                                 Section Info
                  Section       Type    Address   Location Size(Bytes)
                ---------  ---------  ---------  ---------  ---------
           .udata_tasks.o      udata   0x000000       data   0x00004c
                 .tmpdata      udata   0x00004c       data   0x000010
                MATH_DATA      udata   0x00005c       data   0x000004

now, lets see whats un .udata_task.o:

                              Symbols - Sorted by Address
                     Name    Address   Location    Storage
                ---------  ---------  ---------  --------- ---------               
        pxReadyTasksLists   0x000000       data     extern
        xDelayedTaskList1   0x000024       data     static
        xDelayedTaskList2   0x00002d       data     static
        pxDelayedTaskList   0x000036       data     static
pxOverflowDelayedTaskList   0x000038       data     static
        xPendingReadyList   0x00003a       data     static
       xSuspendedTaskList   0x000043       data     static
                  __tmp_0   0x00004c       data     static
                  __tmp_0   0x00004c       data     static

So to my opinion, when retoring the first context for the first task,
my ReadyTasklists and other VERY HANDYDANDY variables are overwritten with
bugus. Stepping with my debugger conforms this.

My question is, is this behaviour known and if so, is there a simple cure?
When building demo projects, the linker places the the .tmpdata and MATH_DATA sections at will in all differrent locations in memory. So none of the
samples worked (they all crash landed).

Thankx in advance!

nobody wrote on Wednesday, April 25, 2007:

Could this be a compiler version issue?  Which version was the port tested with (Richard).

Is there a way of forcing the data to be at 0 using a linker command?


nobody wrote on Wednesday, April 25, 2007:

Is is possible to create a databank in the linker script to exacly fit the .tmpdata and MATH_DATA sections, and use a SECTION directive in the linker script to redirect
these section to the created databank?

And if this is possible, are there restrictions regarding the sort order of these
2 sections in memory? If not, maybe we CAN force these sections to be in this area.

I checked the documentation of the linker and compiler, and could not find any clue
on forcing the data to be at 0.

nobody wrote on Wednesday, April 25, 2007:

hi all
i want know about "primitif of freertos" for a task
help me plaese when you have an idea
thanck u so muth 

nobody wrote on Wednesday, April 25, 2007:

Hey, the solution works!

See the linker script snippet below:

//DATABANK   NAME=gpre       START=0x0            END=0x5F
DATABANK   NAME=gpre       START=0x0            END=0x14            PROTECTED
DATABANK   NAME=gpre2      START=0x15            END=0x5F

Here I split database gpre in 2 parts. The first part just big enough to fit
mu .tmpdata + MATH_DATA size.

This, in conjuction with:

SECTION    NAME=.tmpdata        RAM=gpre
forces the .tmpdata and MATH_DATA sections to this part of memory.

When I Compile,  the map file looks like:

                                 Section Info
                  Section       Type    Address   Location Size(Bytes)
                ---------  ---------  ---------  ---------  ---------
                 .tmpdata      udata   0x000000       data   0x000010
                MATH_DATA      udata   0x000010       data   0x000004
        .udata_croutine.o      udata   0x000015       data   0x000035

This is more like it!

Richard, maybe this is an issue to address in the PIC port of FreeRTOS
documentation perhaps?
As far as I can tell, only newer versions of the compiler do this.

From now, the PIC port of FreeRTOS works as expected :wink:
Thread closed.