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

xNextTaskUnblockTime in tasks.c v7.0.1

Posted by mr4a494d4c on July 19, 2011
Project files:
LPCXpresso Example Projects for LPC11C24 V2.0 (Jan 27, 2011)
http://ics.nxp.com/support/lpcxpresso/
Development Kit: LPCXpresso LPC11C24 REV A board.
IDE / Compiler: code_red Red Suite 3 (NXP Edition) v3.6.3

I commented out everything except tasks:
vTaskLEDBlinker1() and vApplicationIdleHook()

FreeRTOS 5.3.0, blink task and idle task running.
FreeRTOS 6.1.1, blink task and idle task running.
FreeRTOS 7.0.1, blink task runs one time and idle task is still running.

In tasks.c if I change:
PRIVILEGED_DATA static portTickType xNextTaskUnblockTime = ( portTickType ) portMAX_DELAY;

to
PRIVILEGED_DATA static portTickType xNextTaskUnblockTime = 0;

both blink and idle tasks run just fine in FreeRTOS 7.0.1

Not sure what would cause this or where to look?



Some tests I did:

Setting a few breakpoints show this sequence of events out of reset:
main();
vTaskStartScheduler();
vTaskLEDBlinker1();
vApplicationIdleHook();
xPortSysTickHandler();


After that led blink task is not called again using FreeRTOS 7.0.1 but idle task is still running.

I commented out __WFI(); in the idle task with same results.

RE: xNextTaskUnblockTime in tasks.c v7.0.1

Posted by Richard on July 19, 2011
I am not familiar with that code or port at all, so can only comment generically.

Defaulting xNextTaskUnblockTime to 0 will cause the Blocked task list to not be looked at until the tick count had overflowed - which would be a long long time in the future - unless a task entered the Blocked state, which would cause xNextTaskUnblockTime to be set to whatever the unblock time of that task was. In other words, I would not expect it to have any effect, and I could only find out why it did by stepping through the code. I would however, expect that is not related to whatever problem you are having.

Regards.

RE: xNextTaskUnblockTime in tasks.c v7.0.1

Posted by mr4a494d4c on July 20, 2011
xNextTaskUnblockTime is the first variable in RAM at 0x10000000 it gets clobbered by str r4, [r0] in port.c

PORT.C                          ASSEMBLER OUTPUT

" str r0, [r2]\n"0x00001130 : str r0, [r2, #0]
"\n"
" ldr r0, =0x0\n"0x00001132 : movs r0, #0
" ldr r0, [r0]\n"0x00001134 : ldr r0, [r0, #0]
" mov r4, r14\n"0x00001136 : mov r4, lr
" str r4, [r0]\n"0x00001138 : str r4, [r0, #0]
" msr msp, r0\n"0x0000113a : msr MSP, r0
"\n"
" mov r0, %0\n"0x0000113e : movs r0, #0
" msr basepri, r0\n"0x00001140 : msr BASEPRI, r0
" bl vTaskSwitchContext\n"0x00001144 : bl 0x95c


Debug single step.
movs r0, #0r0 = 0
ldr r0, [r0, #0]r0 = 0x10002000
mov r4, lrr4 = 0xfffffff9
str r4, [r0, #0]This instruction stores 0xfffffff9 to 0x10000000 instead of 0x10002000 clobbering
any variable located at 0x10000000 which just happens to be xNextTaskUnblockTime
in my case.


I moved start of RAM up to 0x10000100 so no variables are stored in the first 256 positions and it works fine.
Also notice that ldr r0, =0x0 is replaced with movs r0, #0 after assembly, I tried sub r0, r0 with same results.
I also ran this code on a LPC1114/302 with same results.

Any ideas on why str r4, [r0, #0] writes to the wrong address would be appreciated.

RE: xNextTaskUnblockTime in tasks.c v7.0.1

Posted by Richard on July 20, 2011
Ok - so usual caveats apply - we are talking about unofficial/unsupported code here that I did not write. Also be aware of this post today: http://interactive.freertos.org/entries/20295001-lpc11xx-cortex-m0-freertos-v7-0-0-using-gcc-codered which I think may have corrected something in the M0 port you are using too.


“ldr r0, =0x0 is replaced with movs r0, #0 after assembly”


I think the two are equivalent, and assemblers will often replace pseudo instructions with real instructions, or more efficient versions of instructions that have the same effect. I shouldn't worry about that, unless somebody more familiar with assembly wants to correct that statement.

Looking at this code for the first time, and not knowing what it relates to on an M0 as it looks very different to the M3 official code for the same function, I will try and interpret what you are saying step by step.

movs  r0, #0r0 = 0


Loading R0 with the value 0. Fair enough.

ldr   r0, [r0, #0]


De-reference the address in r0 to get the value stored at the address held in r0, with offset 0. Getting the value of the data stored at address zero seems odd? Can you explain that, are there any comments in the code? Could you post the code as it appears as input (as it appear in the C file?).

mov   r4, lr


Move the link register into r4 - which contains the exception return value 0xfffffff9.

str   r4, [r0, #0]


Store the saved link register value into the address pointed to by r0. No idea what that is intended to achieve.


Until I write this port myself I don't really want to get bogged down in debugging somebody elses code, but if you could look at the link I gave above (which is apparently a bug fix in the NXP LPC1100 code), and if that does not help, post the code as it appears in the source file, with any comments, then I may be able to offer some hints. As it is now, I don't know what the code is supposed to be doing, but agree it looks odd that address 0x10000000 is written to if R0 does indeed contain 0x10002000. I would have to understand the memory map too, if there is a logical explanation.

Regards.




RE: xNextTaskUnblockTime in tasks.c v7.0.1

Posted by Richard on July 20, 2011
...addition, can you look in the map file to see what is at address 0x00 (what is de-referenced), what is at address 0x10000000 and what is at address 0x10002000.

Regards.

RE: xNextTaskUnblockTime in tasks.c v7.0.1

Posted by mr4a494d4c on July 20, 2011
I solved the problem. Your last question pointed me in the right direction.
Again thanks for your time and help.


The vector table is placed at start of RAM, the first two items are:
The first location in RAM 0x10000000 is the initial stack pointer _vStackTop (0x10002000) gets put into SP out of reset and is defined in the linker file.
The second location in RAM 0x10000004 is the address of ResetISR() gets put into PC out of reset.


The linker file:
Defines _vStackTop as (0x10000000 + 0x2000) // Top of 8K RAM and grows down, this gets put into initial stack pointer. OK so far.
The LPC11C24 has 8K of RAM.

The code needs a place to store the link register temporarily and it uses the initial stack pointer address 0x10002000.
Well the address 0x10002000 points past the 8K RAM in hardware so it wraps around and points to 0x10000000 clobbering any variable sitting there.


Snippet from xPortPendSVHandler( void )

" ldr r0, =0x0\n" /* cm0 has fixed vector table at address 0x0 */
" ldr r0, [r0]\n" /* Get initial stack pointer address (0x10002000)*/
" mov r4, r14\n" /* Load link register in r4 */
" str r4, [r0]\n" /* Save r14 */ Save r14 to 0x10002000 which wraps around and points to 0x10000000




RE: xNextTaskUnblockTime in tasks.c v7.0.1

Posted by Richard on July 21, 2011
Glad you are up and running now - and thanks for taking the time to post a detailed explanation.

Regards.

RE: xNextTaskUnblockTime in tasks.c v7.0.1

Posted by mr4a494d4c on July 22, 2011
For completeness, a correction to my previous post.
The vector table is placed in FLASH at address 0x00000000 not RAM.

The vector table is placed at start of FLASH, the first two items are:
The first location in FLASH 0x00000000 is the initial stack pointer _vStackTop (0x10002000) gets put into SP out of reset and is defined in the linker file.
The second location in FLASH 0x00000004 is the address of ResetISR() gets put into PC out of reset.


[ 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