There is something strange happening here in the Hightec GCC startup code. The initialisation of the class data is being done by core0 which is correct but then core1 is trying to do the same thing and overwriting the class data with 0. We will consult Hightec about this to find out why! The class data for myClassC1 is indeed in the DSPR1 RAM.
Attached is a fixed startup code that resolves the issue.
Please note that this is very much a workaround. One of the side effects will be that variables in the core 1 RAM (DSPR1) will not be initialised before getting to setup1() so you would have to explicitly do this at the start of setup1().
This issue has exposed a weakness in the C++ language as there is not really a proper way to assign the class variables to specific memory devices. A better approach might be to put the C0 and C1 classes into the LMU RAM instead. This has fast access from all cores.
/* LMU uninitialised data */ StartOfInitialised_LMURam_Variables /* Put your LMU RAM fast access variables that have an initial value here e.g. uint32 LMU_var_init = 1; */ MyClass myClassC0("C0", 23); MyClass myClassC1("C1", 38); EndOfInitialised_LMURam_Variables