I am having to use the IDE to fill RAM with all zeros to get my Cygnal port to run. Any ideas on this would be appreciated

I remember I had a similar problem after the first run through on the debugger. The first time the memory initialized properly, after that not.

Make sure you are not using the --no-xinit-opt compile time option as this will prevent initialization.

I would suggest trying the silabs.com support forum/email and the SDCC mailing lists. Both are good.

With the latest IDE version I have a problem stepping through code that is not in the main.c file. main.c works fine but other source files don't seem to exist to the debugger. Any ideas on that?

The problem I have is that I can run through the
first part of "main.c" before the RTOS boots just fine, but the tasks will not initialize and run unless I fill the RAM with zeros-- The compiler options are straight from the make file that was with the RTOS files, and have the RAM initialization in them, but they do not initialize all of RAM, just the Variables, and not the XDATA part of RAM which is what I'm filling to get the tasking to run correctly. I Think I could write my own initialization routine that would do this, and it would work, but did not know why this was needed.

Have you checked the return value of the task creation function? It is possible that the memory is not being allocated correctly if the memory allocator is not initialised correctly during the startup.

In heap_1.c there is a function vPortInitialiseBlocks() that clears a variable used by the allocator. Try doing the same in the allocator you are using.

Can you tell me the version of SDCC you are using.

Regards.

I am using SDCC v2.4.0 with FreeRTOS V2.5.4 and IDE V2.3.1

The memory allocator function in Heap_1.c gets called 51 times if Ram is cleared, but only 32 times if not cleared -- the copy stack-ram hangs when the scheduler starts -- Non zero data in Ram must stop the allocation from going to the end of RAM, unless RAM is cleared.

These are the variables that must be filled to zero manually -- will try and isolate which one causes things to hang. Not sure why the initialization does not work correctly -- ??

/* File private variables. --------------------------------*/
static portSHORT sUsingPreemption = pdFALSE;
static unsigned portSHORT usCurrentNumberOfTasks = ( unsigned portSHORT ) 0;
static volatile portTickType xTickCount = ( portTickType ) 0;/* Modified by tick ISR. */
static unsigned portCHAR ucTopUsedPriority = tskIDLE_PRIORITY;
static volatile unsigned portCHAR ucTopReadyPriority = tskIDLE_PRIORITY;
static signed portCHAR cSchedulerRunning = pdFALSE;
static volatile unsigned portCHAR ucSchedulerSuspended = pdFALSE;
static volatile unsigned portCHAR ucMissedTicks = ( unsigned portCHAR ) 0;

Adding this initialization code seems to clear up the issue -- It is like there is a bug in the compiler that is keeping the static var's from being initialized,
or my compiler install was corrupted somehow, or ??


void vTaskInitialiseVars( void )
{

/* File private variables. --------------------------------*/
sUsingPreemption = pdFALSE;
usCurrentNumberOfTasks = ( unsigned portSHORT ) 0;
xTickCount = ( portTickType ) 0;/* Modified by tick ISR. */
ucTopUsedPriority = tskIDLE_PRIORITY;
ucTopReadyPriority = tskIDLE_PRIORITY;
cSchedulerRunning = pdFALSE;
ucSchedulerSuspended = pdFALSE;
ucMissedTicks = ( unsigned portCHAR ) 0;
}

Thats good ... does this happen the first run with the debugger or just following runs?

Without the explicit initialization code, The RTOS will not even run on the first run with or without the debugger (except, once in a while -- possibly when the right variable is in the correct range to run) The compiler should initialize the variables, but I'm not sure why it is not doing the initialization at this point.

Traced it to the compiler -- The SDCC group gave a link to the latest baseline of the compiler. (V2.4.8)