Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

PIC18 Memory corruption during context restor

Posted by Nobody/Anonymous on 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
etc.
"

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
etc...
"


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!

RE: PIC18 Memory corruption during context restor

Posted by Nobody/Anonymous on 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?

Dave.

RE: PIC18 Memory corruption during context restor

Posted by Nobody/Anonymous on 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.



comptechouikha

Posted by Nobody/Anonymous on 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

RE: PIC18 Memory corruption during context restor

Posted by Nobody/Anonymous on 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=0x14PROTECTED
DATABANK NAME=gpre2 START=0x15END=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=.tmpdataRAM=gpre
SECTION NAME=MATH_DATARAM=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 ;)
Thread closed.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists