[quote user="Steven Connell"]Is it possible that what you're doing in your two tasks is taking up a lot of stack space?[/quote]
At this point the task are doing nothing but calling Task_sleep(100). However the stack is already corrupted on entry to the first task...before any task code is run.
[quote user="Steven Connell"]Can you clarify on this? What is this object, how big is it, is it a local variable (allocated on the Task stack) or is it dynamically allocated?[/quote]
Below is the exact code, so it will get allocated onto the task's stack. Keep in mind that the task has not gotten to the declaration yet so the object constructor has not been called. I have not tied allocating it from the heap...I'll try that.
Driver_Dac Dac(Port_1, 0);
[quote user="Steven Connell"]BIOS_start doesn't return so at that this point the Task scheduler should be running. It doesn't look to me like your stack is being corrupted, rather it is being used to store information onto when the task runs.[/quote]
Correct BIOS_start doesn't return that was a poor choice of words. It does invoke the task scheduler which calls any pending task, however the stack is corrupted. Going through the scheduler you will get to 'Task_checkStacks' which checks for stack overflows. This function checks to see if the stack pointer is pointing to 0xBE which it's not.
Your thinking that I missed your point about the task pushing to much stuff on it's stack. I'm not. My point is that the stack is corrupted before task entry.
Here's two new data points. I have two task. Which ever task I declare/create first, either statically or dynamically, is the one that will get hosed.
While watching the task's stack and stepping through the BIOS code...the first task's stack changes!
This screams a SYS/BIOS configuration issue. It looks like the BIOS stack and/or heap is too short and running into the first tasks stack. I have moved/allocated/tried everything I can think of...and the first task called dies.
For what it's worth here's my last map file, but I'm flailing about too much to describe my current configuration. I can tell you that the tasks stacks are in the .far section.
ENTRY POINT SYMBOL: "_c_int00" address: 0082cba0
MEMORY CONFIGURATION
name origin length used unused attr fill
---------------------- -------- --------- -------- -------- ---- --------
L2SRAM 00800000 00080000 0003e444 00041bbc RW X
L1PSRAM 00e00000 00008000 00000000 00008000 RW X
L1DSRAM 00f00000 00008000 00002000 00006000 RW
MSMCSRAM 0c000000 00400000 00000000 00400000 RW X
DDR3 80000000 10000000 00106186 0fef9e7a RW X
SEGMENT ALLOCATION MAP
run origin load origin length init length attrs members
---------- ----------- ---------- ----------- ----- -------
00800000 00800000 00039120 00039120 r-x
00800000 00800000 00039120 00039120 r-x .text
00839120 00839120 000031cc 00000000 rw-
00839120 00839120 000031cc 00000000 rw- .far
0083c2f0 0083c2f0 00001a44 00001a44 rw-
0083c2f0 0083c2f0 00001a44 00001a44 rw- .fardata
0083dd34 0083dd34 0000035c 0000035c r--
0083dd34 0083dd34 0000035c 0000035c r-- .switch
0083e090 0083e090 00000120 00000000 rw-
0083e090 0083e090 00000120 00000000 rw- .cio
0083e1b0 0083e1b0 00000078 00000078 r--
0083e1b0 0083e1b0 00000078 00000078 r-- .init_array
0083e228 0083e228 00000014 00000000 rw-
0083e228 0083e228 00000014 00000000 rw- .bss
0083e23c 0083e23c 0000000c 0000000c rw-
0083e23c 0083e23c 0000000c 0000000c rw- .neardata
0083e400 0083e400 00000200 00000200 r-x
0083e400 0083e400 00000200 00000200 r-x .vecs
00f00000 00f00000 00002000 00000000 rw-
00f00000 00f00000 00002000 00000000 rw- .stack
80000000 80000000 00100000 00000000 rw-
80000000 80000000 00100000 00000000 rw- systemHeap
80100000 80100000 00004d12 00004d12 r--
80100000 80100000 00004d12 00004d12 r-- .const
80104d14 80104d14 00001474 00001474 r--
80104d14 80104d14 00001474 00001474 r-- .cinit