Regarding issue variable reinitialization after reset

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Not applicable
Hello Team,

I would like to request you issue related to variable reinitialization after reset.I want to intialize one global variable, which should not be reintialized after reset.please let me know the solution.please find the compiler details below.

Compiler:Tasking


Regards,
Arundhati B
0 Likes
28 Replies
µC_Wrangler
Employee
Employee
50 solutions authored 100 sign-ins 25 likes received
arundhatib wrote:
I would like to request you issue related to variable reinitialization after reset.I want to intialize one global variable, which should not be reintialized after reset.please let me know the solution.please find the compiler details below.

Compiler:Tasking

Hello Arundhati. You can find an example in Tasking's ctc_user_guide.pdf, section 8.8.8 The Section Layout Definition: Locating Sections. The noclear and lsl definition of .zbss.non_volatile are the key points.

Be aware that the BootROM can overwrite up to 8K at the start of CPU0 DSPR - so you'll want to make sure your definition is outside of that range.
0 Likes
Not applicable
Hello,
Thank you for the reply.

I have used below instructions as mentioned in the "ctc_user_guide.pdf",example.still i the global variable Gul_Test_Flag is resetting to 0. please find the below instructions and cases i have tested.
1:
#pragma section all "non_volatile"
#pragma noclear
volatile unsigned int Gul_Test_Flag;
#pragma clear
#pragma section all

2:
#pragma section all "non_volatile"
#pragma noclear
volatile unsigned int Gul_Test_Flag;
0 Likes
µC_Wrangler
Employee
Employee
50 solutions authored 100 sign-ins 25 likes received
arundhatib wrote:
I have used below instructions as mentioned in the "ctc_user_guide.pdf",example.still i the global variable Gul_Test_Flag is resetting to 0. please find the below instructions and cases i have tested.
1:
#pragma section all "non_volatile"
#pragma noclear
volatile unsigned int Gul_Test_Flag;
#pragma clear
#pragma section all

Did you also modify the lsl file? Please post that here or send it in a private message.

Regards,
Neal
0 Likes
lock attach
Attachments are accessible only for community members.
Not applicable
Hello Neal,

Thank you for your response.

Please find the compiler,linker batch files and .lsl(tc27x) file in the attachment.


Thanks and Regards,
Arundhati B
0 Likes
µC_Wrangler
Employee
Employee
50 solutions authored 100 sign-ins 25 likes received
I don't see any definition for non_volatile in your linker file.

Here's an example that should help. This example is based on the TC23x:

C file:
#pragma section all "non_volatile"
#pragma noclear
__far volatile int nvram_i;
__far volatile int nvram_j;
#pragma clear
#pragma section all

int main(void)
{
nvram_i = 4;
nvram_j = 2;
}


LSL file:

#include "tc23x.lsl"

section_layout :vtc:linear
{
// reserve last 2K of TC23x DSPR for non-volatile variables
group( ordered, run_addr = [0x7002d800..0x7002e000] )
{
select ".bss.non_volatile";
}
}


You can verify that the variables ended up where you wanted in the map file:

| Chip | Group | Section | Size (MAU) | Space addr | Chip addr | Alignment |
| mpe:dspr0 | | .bss.non_volatile (92) | 0x00000004 | 0x7002d800 | 0x0002d800 | 0x00000002 |
| mpe:dspr0 | | .bss.non_volatile (93) | 0x00000004 | 0x7002d804 | 0x0002d804 | 0x00000002 |
0 Likes
lock attach
Attachments are accessible only for community members.
Not applicable
Hello Neal,

I have tested as you mentioned in the reply, but still variables are resetting to 0 after reset. Please find modified *.lsl and code along with the observed output memory in the attachements. Please find in attached files that setting variables (before reset) and clearing of variables value after reset.


Thanks and Regards,
Arundhati B
0 Likes
µC_Wrangler
Employee
Employee
50 solutions authored 100 sign-ins 25 likes received
arundhatib wrote:
I have tested as you mentioned in the reply, but still variables are resetting to 0 after reset.

Two roadblocks left:

First, your address is still within the first 8K of RAM, which is used by the BootROM. Move your non_volatile block somewhere out of the first 0x2000 bytes.

Second, unless you've modified UCB_DFLASH, the default value of PROCOND.RAMIN is 00b (Init_All), and RAMINSEL is 0000b. This means that the BootROM initializes all RAMs (PSPR, DSPR, PCACHE, and DCACHE) after every reset. Infineon Memtool 4.6.2 lets you edit UCB_DFLASH easily: select Device / UCBs / UCB_DFLASH, and change RAMIN to 2 (Init RAM only after cold power-on reset). Remember to Write the configuration.

You can also write UCB_DFLASH through most debuggers - but tread carefully, since they usually don't implement many safeguards. Writing incorrect values to UCB_DFLASH can lock features out permanently.
0 Likes
Not applicable
Hello Neal,

My name is Nayan Patel and I am new to this forum. I am facing the similar issue with Tricore Aurix TC23x.

I am writing some variable value and then performing micro internal WD reset. I want to NOT initialize this variable after this reset and want it retain its value from before the reset.

For doing that I used the pragma that you referred in the previous answer and also modified the .lsl file. I can see in the map file that the variable is placed at desired location (0x70002000) in dspr but still after WD reset, the variable value goes zero. I have checked the FLASH0_PROCOND register and the RAMIN value is init_all. Is it the problem? When I placed the variable to dspr location, still do I need to change RAMIN value?

Thanks for your help in advance.
0 Likes
User9888
Level 3
Level 3
ndpatel1234 wrote:
Hello Neal,

My name is Nayan Patel and I am new to this forum. I am facing the similar issue with Tricore Aurix TC23x.

I am writing some variable value and then performing micro internal WD reset. I want to NOT initialize this variable after this reset and want it retain its value from before the reset.

For doing that I used the pragma that you referred in the previous answer and also modified the .lsl file. I can see in the map file that the variable is placed at desired location (0x70002000) in dspr but still after WD reset, the variable value goes zero. I have checked the FLASH0_PROCOND register and the RAMIN value is init_all. Is it the problem? When I placed the variable to dspr location, still do I need to change RAMIN value?

Thanks for your help in advance.


HI Nayan,

Note that Neal uses two pragma's in the above thread. One to rename a section so as to be able to locate it using LSL. And another to instruct the compiler not to create clear sections. Just to be sure, did you use both of them as well?

Best regards,

Henk-Piet Glas
Technical Product Specialist
0 Likes
User12342
Level 1
Level 1
Hi All,

Could you please tell me how is it possible to assign a value to FLASH0_PROCOND register?

The following produces trap:

FLASH0_PROCOND.U = 0x00000008UL;

Thank you in advance for the reply.
Best regards,
Balazs Brosch
0 Likes
User20083
Level 3
Level 3
25 replies posted 10 replies posted 5 replies posted
Was this resolved? I am still having an issue.

PROCOND is 0.
Ram variables are reset on __init_sp()
pragma noclear __far and section naming has been used.
My variables are in loc 0x7002c000 which is away for the 8k that bootrom uses.

It still resets on SWRSTREQ assertion and reset.
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
Which Aurix device are you referring to? In Aurix 2G devices, PROCOND is a read only register - the values are set from what is programmed into the UCBs. To change PROCOND, it is necessary to change the contents of UCB_DFLASH - the modified contents will be reloaded on reset. You should expect a bus error if you try and directly write to the register.
0 Likes
User20083
Level 3
Level 3
25 replies posted 10 replies posted 5 replies posted
The TC234

Before using memtool, I am trying to figure out why the memory locations are being cleared.

I am using tasking to compile my code. (The same code in hightec toolchain works fine and the variables are left as is).
The only code differences I have noticed so far is that tasking uses cstartx.c and hightec uses IfxCpu_Cstartx.c and different linker files.

I can confirm that my variables are being located in the right linker sections.
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
Please post how your variables are declared (with any #pragmas), your map file, and lsl file.
0 Likes
User20083
Level 3
Level 3
25 replies posted 10 replies posted 5 replies posted
The variables defined in proc_variables.h are
#pragma noclear
extern volatile uint16 __far MoSt_ram_g ;
extern volatile uint16 __far MoSt_ram_ig ;
#pragma clear


The map file section is :


+ Space mpe:vtc:linear (MAU = 8bit)

+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Chip | Group | Section | Size (MAU) | Space addr | Chip addr | Alignment |
|==================================================================================================================================================================================|
| mpe:dspr0x | | .bss.proc_variables.MoSt_ram_g (5004) | 0x00000002 | 0x7002c000 | 0x0 | 0x00000002 |
| mpe:dspr0x | | .bss.proc_variables.MoSt_ram_ig (5005) | 0x00000002 | 0x7002c002 | 0x00000002 | 0x00000002 |



The linker file additions are :

// TASKING VX-toolset for TriCore
// Eclipse project linker script file
//
#if defined(__PROC_TC23X__)
#define __REDEFINE_ON_CHIP_ITEMS
#include "tc23x.lsl"
processor mpe
{
derivative = my_tc23x;
}
derivative my_tc23x extends tc23x
{
memory dspr0 (tag="on-chip")
{
mau = 8;
type = ram;
size = 176k;
priority = 1;
exec_priority = 0;
map (dest=bus:tc0:fpi_bus, dest_offset=0xd0000000, size=176k, priority=1, exec_priority=0);
map (dest=bus:sri, dest_offset=0x70000000, size=176k);
}
memory dspr0x (tag="on-chip")
{
mau = 8;
type = ram;
size = 8k;
priority = 1;
exec_priority = 0;
map (dest=bus:sri, dest_offset=(0x7002E000-0x2000), size=8k);
}
memory pspr0 (tag="on-chip")
{
mau = 8;
type = ram;
size = 8k;
priority = 0;
exec_priority = 1;
map (dest=bus:tc0:fpi_bus, dest_offset=0xc0000000, size=8k, exec_priority=1);
map (dest=bus:sri, dest_offset=0x70100000, size=8k);
}
memory pflash0 (tag="on-chip")
{
mau = 8;
type = rom;
size = 2M;
map cached(dest=bus:sri, dest_offset=0x80000000, size=2M);
map not_cached(dest=bus:sri, dest_offset=0xa0000000, size=2M, reserved);
}
memory brom (tag="on-chip")
{
mau = 8;
type = reserved rom;
size = 32k;
map cached(dest=bus:sri, dest_offset=0x8fff8000, size=32k);
map not_cached(dest=bus:sri, dest_offset=0xafff8000, size=32k, reserved);
}
memory dflash0 (tag="on-chip")
{
mau = 8;
type = reserved nvram;
size = 128k+16k;
map (dest=bus:sri, src_offset=0, dest_offset=0xaf000000, size=128k);
map (dest=bus:sri, src_offset=128k, dest_offset=0xaf100000, size=16k);
}

section_layout :vtc:linear
{
group ( run_addr=mem:dspr0x)
{
select "(*.bss.proc_variables*)";
}
}

}
#else
#include
#endif
0 Likes
MoD
Employee
Employee
50 likes received 500 replies posted 100 solutions authored
Where are the variables defined? I guess that the #pragma noclear is ignored in this case because of the extern declaration of the variables. #pragma noclear must be put where the variables are defined.
0 Likes
User20083
Level 3
Level 3
25 replies posted 10 replies posted 5 replies posted
If I declare them in the module file where they are used as follows:


#pragma section all "proc_variables"
#pragma noclear
static volatile uint16 __far MoSt_ram_g ;
static volatile uint16 __far MoSt_ram_ig ;
#pragma clear
#pragma section all


it still clears the variables on reset.

The new map file section is:

+ Space mpe:vtc:linear (MAU = 8bit)

+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Chip | Group | Section | Size (MAU) | Space addr | Chip addr | Alignment |
|==================================================================================================================================================================================|

| mpe:dspr0x | | .bss.proc_variables (5032) | 0x00000002 | 0x7002c000 | 0x0 | 0x00000002 |
| mpe:dspr0x | | .bss.proc_variables (5033) | 0x00000002 | 0x7002c002 | 0x00000002 | 0x00000002 |


and the linker is the same as before:

	section_layout :vtc:linear 
{
group (run_addr=mem:dspr0x)
{
select "(*.bss.proc_variables*)";
}
}


The clearing occurs immediately after reset is requested and before system startup even occurs i.e before __init_sp();
void _START( void )
{
__init_sp();
}
in cstart.c is run
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
Hmm. SWRSTSEQ doesn't cause a warm or cold power on reset, but could the debugger or an external watchdog be involved?

Can you try changing PROCOND.RAMIN to 3 (no init) in UCB_DFlash and see if the behavior changes?
0 Likes
lock attach
Attachments are accessible only for community members.
User20083
Level 3
Level 3
25 replies posted 10 replies posted 5 replies posted
I've made the changes with PROCOND and the register is set successfully but no luck. The variables are still being cleared.

Watchdog is working normally and doesn't affect the variables (I've enabled/disabled it and it makes no difference). WDT Registers show no overflow or reset requests.

SCU_RSTCON register shows the resets are being triggered by SW which is what I expect. So there are no unexpected triggers causing resets.

I have used the tasking debugger as well as the UDE. In both cases the variables get cleared.

Here's the peculiar bit:
I have two projects with exactly the same application code.

One uses the hightec compiler -
It uses the IfxCpu_CStart0.c startup file
It uses the following linker file

The other uses the tasking compiler -
It uses the cstart.c startup file
It uses the following linker file



The hightec project works perfectly. The ram variables are uninitialized and resets do not affect their state.
The tasking project resets the ram immediately after resets are triggered.

In all cases IFX_CFG_USE_COMPILER_DEFAULT_LINKER has never been defined
0 Likes
User20083
Level 3
Level 3
25 replies posted 10 replies posted 5 replies posted
Hi,

Any update on this?
0 Likes
MoD
Employee
Employee
50 likes received 500 replies posted 100 solutions authored
The problem is not the HW, as you wrote it works with HighTec Compiler. Can you add here your used lsl and map file for/from Tasking?
0 Likes
lock attach
Attachments are accessible only for community members.
User20083
Level 3
Level 3
25 replies posted 10 replies posted 5 replies posted
LSL File:
// TASKING VX-toolset for TriCore
// Eclipse project linker script file
//
#if defined(__PROC_TC23X__)
#define __REDEFINE_ON_CHIP_ITEMS
#include "tc23x.lsl"
processor mpe
{
derivative = my_tc23x;
}
derivative my_tc23x extends tc23x
{
memory dspr0 (tag="on-chip")
{
mau = 8;
type = ram;
size = 176k;
priority = 1;
exec_priority = 0;
map (dest=bus:tc0:fpi_bus, dest_offset=0xd0000000, size=176k, priority=1, exec_priority=0);
map (dest=bus:sri, dest_offset=0x70000000, size=176k);
}
memory dspr0x (tag="on-chip")
{
mau = 8;
type = ram;
size = 8k;
priority = 1;
exec_priority = 0;
map (dest=bus:sri, dest_offset=(0x7002E000-0x2000), size=8k);
}
memory pspr0 (tag="on-chip")
{
mau = 8;
type = ram;
size = 8k;
priority = 0;
exec_priority = 1;
map (dest=bus:tc0:fpi_bus, dest_offset=0xc0000000, size=8k, exec_priority=1);
map (dest=bus:sri, dest_offset=0x70100000, size=8k);
}
memory pflash0 (tag="on-chip")
{
mau = 8;
type = rom;
size = 2M;
map cached(dest=bus:sri, dest_offset=0x80000000, size=2M);
map not_cached(dest=bus:sri, dest_offset=0xa0000000, size=2M, reserved);
}
memory brom (tag="on-chip")
{
mau = 8;
type = reserved rom;
size = 32k;
map cached(dest=bus:sri, dest_offset=0x8fff8000, size=32k);
map not_cached(dest=bus:sri, dest_offset=0xafff8000, size=32k, reserved);
}
memory dflash0 (tag="on-chip")
{
mau = 8;
type = reserved nvram;
size = 128k+16k;
map (dest=bus:sri, src_offset=0, dest_offset=0xaf000000, size=128k);
map (dest=bus:sri, src_offset=128k, dest_offset=0xaf100000, size=16k);
}

section_layout :vtc:linear
{
group (run_addr=mem:dspr0x)
{
select "(*.bss.my_vars*)";
}
}

}
#else
#include
#endif




The Map file and source files used
0 Likes
MoD
Employee
Employee
50 likes received 500 replies posted 100 solutions authored
Add a name to the group for your variables, e.g. group noclear (run_addr...
Then have a look in the map file if your variables are added to this group...
0 Likes
MoD
Employee
Employee
50 likes received 500 replies posted 100 solutions authored
Your variables are part of the normal bss section and therefore initialized. Check what happens when you rename .bss.my_vars to .bss_myvars
0 Likes
User20083
Level 3
Level 3
25 replies posted 10 replies posted 5 replies posted
Hi I named the group "my_group" and it looks like the linker has added the variables to the correct group.


+ Space mpe:vtc:linear (MAU = 8bit)

+---------------------------------------------------------------------------------------------------------------------------------------------+
| Chip | Group | Section | Size (MAU) | Space addr | Chip addr | Alignment |
|=============================================================================================================================================|
| mpe:dspr0 | | .bss._dbg_request.libcs_fpu (5281) | 0x00000014 | 0x70000400 | 0x00000400 | 0x00000004 |
| mpe:dspr0 | | .bss._malloc_start.libcs_fpu (5123) | 0x00000004 | 0x70000414 | 0x00000414 | 0x00000004 |
| mpe:dspr0 | | .bss.stdin_buf.libcs_fpu (5171) | 0x00000050 | 0x70000418 | 0x00000418 | 0x00000001 |
| mpe:dspr0 | | .bss.stdout_buf.libcs_fpu (5172) | 0x00000050 | 0x70000468 | 0x00000468 | 0x00000001 |
| mpe:dspr0 | | .data._iob.libcs_fpu (5173) | 0x000000c8 | 0x700004b8 | 0x000004b8 | 0x00000004 |
| mpe:dspr0 | | .data.__clocks_per_sec.libcs_fpu (4989) | 0x00000008 | 0x70000580 | 0x00000580 | 0x00000004 |
| mpe:dspr0 | | .data._end.libcs_fpu (5132) | 0x00000004 | 0x70000588 | 0x00000588 | 0x00000004 |
| mpe:dspr0 | | heap (5380) | 0x00004000 | 0x70009000 | 0x00009000 | 0x00000008 |
| mpe:dspr0x | my_group | .bss.my_vars.My_Var16 (111) | 0x00000004 | 0x7002c000 | 0x0 | 0x00000002 |
| mpe:dspr0x | my_group | .bss.my_vars.My_Var32 (112) | 0x00000004 | 0x7002c004 | 0x00000004 | 0x00000002 |


Again, the issue doesn't seem to be with linking the variables. While debugging, I can see them being written to without an errors.

Your variables are part of the normal bss section and therefore initialized. Check what happens when you rename .bss.my_vars to .bss_myvars

Bit confused. What would you like me to do? Rename the select section?
0 Likes
MoD
Employee
Employee
50 likes received 500 replies posted 100 solutions authored
I checked your file, there is everything fine. The variables are not reset by HW or SW. It seems that there is a problem in your debugger which reset this two addresses or you see a wrong value in the debugger.
0 Likes
User20083
Level 3
Level 3
25 replies posted 10 replies posted 5 replies posted
Hi MoD,

I replaced the default lsl file with this one that I found in an example (github examples) project and used the IFxCStart0.c files for startup

/*
* \file Lcf_Tasking_Tricore_Tc.lsl
* \brief Linker command file for Tasking compiler.
* \copyright Copyright (C) Infineon Technologies AG 2019*/

#define LCF_CSA0_SIZE 8k
#define LCF_USTACK0_SIZE 2k
#define LCF_ISTACK0_SIZE 1k

#define LCF_HEAP_SIZE 2k

#define LCF_CPU0 0

#define LCF_DEFAULT_HOST LCF_CPU0

#define LCF_DSPR0_START 0x70000000
#define LCF_DSPR0_SIZE 184k

#define LCF_CSA0_OFFSET (LCF_DSPR0_SIZE - 1k - LCF_CSA0_SIZE)
#define LCF_ISTACK0_OFFSET (LCF_CSA0_OFFSET - 256 - LCF_ISTACK0_SIZE)
#define LCF_USTACK0_OFFSET (LCF_ISTACK0_OFFSET - 256 - LCF_USTACK0_SIZE)

#define LCF_HEAP0_OFFSET (LCF_USTACK0_OFFSET - LCF_HEAP_SIZE)

#define LCF_INTVEC0_START 0x801F4000
#define LCF_TRAPVEC0_START 0x80000100

#define INTTAB0 (LCF_INTVEC0_START)
#define TRAPTAB0 (LCF_TRAPVEC0_START)

#define RESET 0x80000020

#include "tc1v1_6_x.lsl"

// Specify a multi-core processor environment (mpe)

processor mpe
{
derivative = tc23A;
}

derivative tc23A
{
core tc0
{
architecture = TC1V1.6.X;
space_id_offset = 100; // add 100 to all space IDs in the architecture definition
copytable_space = vtc:linear; // use the copy table in the virtual core for 'bss' and initialized data sections
}

core vtc
{
architecture = TC1V1.6.X;
import tc0; // add all address spaces of core tc0 to core vtc for linking and locating
}

bus sri
{
mau = 8;
width = 32;

// map shared addresses one-to-one to real cores and virtual cores
map (dest=bus:tc0:fpi_bus, src_offset=0, dest_offset=0, size=0xc0000000);
map (dest=bus:vtc:fpi_bus, src_offset=0, dest_offset=0, size=0xc0000000);
}

memory dsram0 // Data Scratch Pad Ram
{
mau = 8;
size = 184k;
type = ram;
map (dest=bus:tc0:fpi_bus, dest_offset=0xd0000000, size=184k, priority=8);
map (dest=bus:sri, dest_offset=0x70000000, size=184k);
}

memory psram0 // Program Scratch Pad Ram
{
mau = 8;
size = 8k;
type = ram;
map (dest=bus:tc0:fpi_bus, dest_offset=0xc0000000, size=8k, priority=8);
map (dest=bus:sri, dest_offset=0x70100000, size=8k);
}

memory pfls0
{
mau = 8;
size = 2M;
type = rom;
map cached (dest=bus:sri, dest_offset=0x80000000, size=2M);
map not_cached (dest=bus:sri, dest_offset=0xa0000000, reserved, size=2M);
}

memory dfls0
{
mau = 8;
size = 1M;
type = reserved nvram;
map (dest=bus:sri, dest_offset=0xaf000000, size=1M );
}

memory lmuram
{
mau = 8;
size = 32k;
type = ram;
priority = 2;
map cached (dest=bus:sri, dest_offset=0x90000000, size=32k);
map not_cached (dest=bus:sri, dest_offset=0xb0000000, reserved, size=32k);
}

memory edmem
{
mau = 8;
size = 512k;
type = ram;
map (dest=bus:sri, dest_offset=0x9f000000, size=512);
map (dest=bus:sri, dest_offset=0xbf000000, reserved, size=512k);
}

#if (__VERSION__ >= 6003)
section_setup :vtc:linear
{
heap "heap" (min_size = (1k), fixed, align = 8);
}
#endif

section_setup :vtc:linear
{
start_address
(
symbol = "_START"
);
}

section_setup :vtc:linear
{
stack "ustack_tc0" (min_size = 1k, fixed, align = 8);
stack "istack_tc0" (min_size = 1k, fixed, align = 8);
}

/*Section setup for the copy table*/
section_setup :vtc:linear
{
copytable
(
align = 4,
dest = linear,
table
{
symbol = "_lc_ub_table_tc0";
space = :tc0:linear, :tc0:abs24, :tc0:abs18, :tc0:csa;
}
);
}

/*Near data sections*/
section_layout :vtc:abs18
{
group (ordered, contiguous, align = 4, attributes=rw, run_addr = mem:dsram0)
{
select "(.zdata.zdata_cpu0|.zdata.zdata_cpu0*)";
select "(.zbss.zbss_cpu0|.zbss.zbss_cpu0*)";
}
# if LCF_DEFAULT_HOST == LCF_CPU0
group (ordered, contiguous, align = 4, attributes=rw, run_addr = mem:dsram0)
# endif
{
select "(.zdata|.zdata*)";
select "(.zbss|.zbss*)";
}
}

section_layout :vtc:linear
{
/*Small data sections, No option given for CPU specific user sections to make generated code portable across Cpus*/
# if LCF_DEFAULT_HOST == LCF_CPU0
group a0 (ordered, contiguous, align = 4, attributes=rw, run_addr = mem:dsram0)
# endif
{
select "(.sdata |.sdata*)";
select "(.sbss |.sbss*)";
}
"_SMALL_DATA_" := sizeof(group:a0) > 0 ? addressof(group:a0) + 32k : addressof(group:a0) & 0xF0000000 + 32k;

/*Far data sections*/
group (ordered, contiguous, align = 4, run_addr = mem:edmem)
{
select "(.data.edmemdata|.data.edmemdata*)";
select "(.bss.edmembss|.bss.edmembss*)";
}
group (ordered, contiguous, align = 4, run_addr = mem:dsram0)
{
select "(.data.data_cpu0|.data.data_cpu0*)";
select "(.bss.bss_cpu0|.bss.bss_cpu0*)";
}

# if LCF_DEFAULT_HOST == LCF_CPU0
group (ordered, contiguous, align = 4, attributes=rw, run_addr = mem:dsram0)
# endif
{
select "(.data|.data*)";
select "(.bss|.bss*)";
}

/*Heap sections*/
# if LCF_DEFAULT_HOST == LCF_CPU0
group (ordered, align = 4, run_addr = mem:dsram0[LCF_HEAP0_OFFSET])
# endif
{
heap "heap" (size = LCF_HEAP_SIZE);
}

group (ordered, align = 8, run_addr = mem:dsram0[LCF_USTACK0_OFFSET])
{
stack "ustack_tc0" (size = LCF_USTACK0_SIZE);
}
"__USTACK0":= "_lc_ue_ustack_tc0";
"__USTACK0_END":= "_lc_ub_ustack_tc0";

group (ordered, align = 8, run_addr = mem:dsram0[LCF_ISTACK0_OFFSET])
{
stack "istack_tc0" (size = LCF_ISTACK0_SIZE);
}
"__ISTACK0":= "_lc_ue_istack_tc0";
"__ISTACK0_END":= "_lc_ub_istack_tc0";

group (ordered, align = 64, attributes=rw, run_addr=mem:dsram0[LCF_CSA0_OFFSET])
reserved "csa_tc0" (size = LCF_CSA0_SIZE);
"__CSA0":= "_lc_ub_csa_tc0";
"__CSA0_END":= "_lc_ue_csa_tc0";
}


section_layout :vtc:linear
{
"_lc_u_int_tab" = (LCF_INTVEC0_START);
"__INTTAB_CPU0" = (LCF_INTVEC0_START);

// interrupt vector tables for tc0, tc1, tc2
group int_tab_tc0 (ordered)
{
# include "inttab0.lsl"
}

group trapvec_tc0 (ordered, run_addr=LCF_TRAPVEC0_START)
{
select "(.text.traptab_cpu0*)";
}

group code_psram0 (ordered, attributes=rwx, copy, run_addr=mem:psram0)
{
select "(.text.psram_cpu0*)";
select "(.text.cpu0_psram*)";
}
}

section_layout :vtc:abs18
{
group (ordered, run_addr=mem:pfls0)
{
select ".zrodata*";
}
}

section_layout :vtc:linear
{
group my_group (run_addr=mem:dsram0)
{
select "*.bss.ttrd2-19a-t00234a-v001a_proc_vars*";
}
group bmh_0 (ordered, run_addr=0x80000000)
{
select "*.bmhd_0";
}
group bmh_1 (ordered, run_addr=0x80020000)
{
select "*.bmhd_1";
}
group reset (ordered, run_addr=0x80000020)
{
select "*.start";
}
group interface_const (ordered, run_addr=0x80000040)
{
select "*.interface_const";
}
"__IF_CONST" := addressof(group:ainterface_const);
group a1 (ordered, run_addr=mem:pfls0)
{
select ".srodata*";
select ".ldata*";
}
"_LITERAL_DATA_" := sizeof(group:a1) > 0 ? addressof(group:a1) + 32k : addressof(group:a1) & 0xF0000000 + 32k;
"_A1_MEM" = "_LITERAL_DATA_";
"_A9_DATA_" := 0x00000000;
"_A9_MEM" = "_A9_DATA_";

group (ordered, run_addr=mem:pfls0)
{
select ".rodata*";
}
group (ordered, run_addr=mem:pfls0)
{
select ".text*";
}
group a8 (ordered, run_addr=mem:pfls0)
{
select "(.rodata_a8|.rodata_a8*)";
}
"_A8_DATA_" := sizeof(group:a8) > 0 ? addressof(group:a8) + 32k : addressof(group:a8) & 0xF0000000 + 32k;
"_A8_MEM" := "_A8_DATA_";

"__TRAPTAB_CPU0" := TRAPTAB0;
}
}


This solved the issue.

It was not the debugger. It's something in the startup files/linker that configure the processor to erase memory sections on reset.

I will no longer pursue this issue unless I come across it again.

Thank you for your time
0 Likes
babu99
Level 2
Level 2
10 replies posted 5 replies posted 5 sign-ins

Hi,

Anyone is there to explain how the variable is set to not initialize over resets?

Thank you

Babu Dudekula

0 Likes