xNextTaskUnblockTime in tasks.c v7.0.1

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.

xNextTaskUnblockTime in tasks.c v7.0.1

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.

xNextTaskUnblockTime in tasks.c v7.0.1

xNextTaskUnblockTime is the first variable in RAM at 0x10000000 it gets clobbered by  str r4,    in port.c
PORT.C                          ASSEMBLER OUTPUT
" str r0, [r2]      n" 0x00001130 <xPortPendSVHandler+48>:  str   r0, [r2, #0]
"           n"
" ldr r0, =0x0      n" 0x00001132 <xPortPendSVHandler+50>:  movs  r0, #0
" ldr r0, [r0]      n" 0x00001134 <xPortPendSVHandler+52>:  ldr   r0, [r0, #0]
" mov r4, r14       n" 0x00001136 <xPortPendSVHandler+54>:  mov   r4, lr   
" str r4, [r0]      n" 0x00001138 <xPortPendSVHandler+56>:  str   r4, [r0, #0] 
" msr msp, r0       n" 0x0000113a <xPortPendSVHandler+58>:  msr   MSP, r0 
"           n"
" mov r0, %0        n" 0x0000113e <xPortPendSVHandler+62>:  movs  r0, #0
" msr basepri, r0   n" 0x00001140 <xPortPendSVHandler+64>:  msr   BASEPRI, r0
" bl vTaskSwitchContext n" 0x00001144 <xPortPendSVHandler+68>:  bl    0x95c <vTaskSwitchContext>
Debug single step.
movs  r0, #0            r0 = 0
ldr   r0, [r0, #0]      r0 = 0x10002000
mov   r4, lr            r4 = 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,   writes to the wrong address would be appreciated.

xNextTaskUnblockTime in tasks.c v7.0.1

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, #0            r0 = 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.

xNextTaskUnblockTime in tasks.c v7.0.1

…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.

xNextTaskUnblockTime in tasks.c v7.0.1

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

xNextTaskUnblockTime in tasks.c v7.0.1

Glad you are up and running now – and thanks for taking the time to post a detailed explanation. Regards.

xNextTaskUnblockTime in tasks.c v7.0.1

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.