Runtime variables only initialised for Core 0 in iLLD startup code - TC264

[jonnywitt]

I’m having issues during the initialisation of my Aurix TC264. Global variables which are cloned across cores only seem to be initialised in Core0 and not Core1. For reference I’m using HighTec as my development IDE and UDE STK as my debugger. I’m also using Infineon’s 1G iLLDs (v1.13.0) to perform this initialisation.

After doing some debugging it appears that _Core0_start() in IfxCpu_CStart0.c has a call to Ifx_C_Init() , where global variables are initialised for Core0. However, _Core1_start() in IfxCpu_CStart1.c has no such call and therefore seems to keep these variables from being initialised for Core1.

I also ran the same project on a TC377, using the Startup Software (SSW) in the 2G iLLDs. In this case, __Core1_start() in Ifx_Ssw_Tc1.c contains the following lines, which does indeed initialise the global variables for Core1:

    /*Initialize CPU Private Global Variables*/

    //TODO : This implementation is done once all compilers support this

#if (IFX_CFG_SSW_ENABLE_INDIVIDUAL_C_INIT != 0)

    (void)Ifx_Ssw_C_Init();

#endif

One variable I'm looking at in particular is located at 0xD00000000 in my map file, so i believe the linker is working correctly and making it cloned to both cores. I can actually add this variable to "Watches" on UDE and see it get populated for Core0 but not Core1 during this startup stage.

Hopefully you understand my problem, and have a solution to make these runtime variables initialise during startup for both cores. I believe I could add a similar line to the one above into IfxCpu_CStart1.c, but I’m assuming these iLLDs shouldn’t need any editing and should work out of the box.

[µC_Wrangler]

Hi @jonnywitt .  For most executables, the compiler only generates one cinit table, which means you only need to call cinit once.  It could be that Tasking's fancy new safety partitioning generates separate tables - but if it does, that implementation is left to the reader.

So, if you have code with its own local variables placed at local addresses (e.g., 0xD0000000 instead of, say, DSPR1 at 0x60000000), you'd need to take care of initialization in some other way - perhaps by initializing variables in code instead of using static initializers.

Be very careful with using local addressing.  I've had many customers make mistakes with passing pointers using local addressing between CPUs - and nothing good happens after that, because the (non-local) CPU is accessing the wrong data.

[jonnywitt]

Hi @µC_Wrangler , thank you for your response. I'm using HighTec as my compiler, but I believe these CStart files are compiler independent. After reading IfxCpu_CStart.h, I can see as you stated that steps 8, 9 & 10 (global var initialisation, clock config & core start) are "not executed by remaining cores at startup". 

The variables in question are part of "tagged" code so unfortunately I can't play with it, however each core should be using it's own copy of it. Hopefully this should avoid the problem you're talking about.

If the issue isn't in the startup code, I'm thinking I my problem lies in the linker script, as this is an area I'm most unfamiliar with. I'll try and change part of the .ld and post any successes I have

[µC_Wrangler · Accepted solution]

Looking at the TC3xx iLLD implementation further: the cinit is very compiler dependent, because it boils down to an inline version for each compiler (e.g., Ifx_Ssw_CompilersGnuc.h, Ifx_Ssw_C_InitInline).  That function is using the singular global variables __clear_table[] and __copy_table[].

Looking at the Hightec documentation (12.1 Startup code in crt0.o), it looks like gcc (like most compilers) only supports a single clear table and copy table.

So, if you need to use local addressing for CPUs other than CPU0, I'd stay away from using static initializers for those variables.