Not applicable
Aug 12, 2014
01:29 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 12, 2014
01:29 AM
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
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
- Tags:
- IFX
28 Replies
Aug 18, 2014
01:14 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 18, 2014
01:14 PM
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.
Not applicable
Aug 25, 2014
06:28 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 25, 2014
06:28 AM
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;
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;
Aug 25, 2014
11:56 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 25, 2014
11:56 AM
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
Attachments are accessible only for community members.
Not applicable
Aug 26, 2014
01:31 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 26, 2014
01:31 AM
Aug 26, 2014
07:43 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 26, 2014
07:43 AM
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:
LSL file:
You can verify that the variables ended up where you wanted in the map 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 |
Attachments are accessible only for community members.
Not applicable
Aug 27, 2014
02:19 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 27, 2014
02:19 AM
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
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
Aug 27, 2014
01:36 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 27, 2014
01:36 PM
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.
Not applicable
Apr 20, 2016
06:58 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 20, 2016
06:58 AM
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.
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.
Apr 25, 2016
11:12 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 25, 2016
11:12 PM
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
Oct 19, 2016
01:12 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Oct 19, 2016
01:12 AM
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
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
Sep 07, 2020
03:27 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 07, 2020
03:27 AM
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.
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.
Sep 07, 2020
05:33 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 07, 2020
05:33 AM
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.
Sep 07, 2020
06:54 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 07, 2020
06:54 AM
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.
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.
Sep 07, 2020
07:18 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 07, 2020
07:18 AM
Please post how your variables are declared (with any #pragmas), your map file, and lsl file.
Sep 07, 2020
07:26 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 07, 2020
07:26 AM
The variables defined in proc_variables.h are
The map file section is :
The linker file additions 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
Sep 07, 2020
08:35 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 07, 2020
08:35 AM
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.
Sep 07, 2020
11:07 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 07, 2020
11:07 AM
If I declare them in the module file where they are used as follows:
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 |
|==================================================================================================================================================================================|
and the linker is the same as before:
The clearing occurs immediately after reset is requested and before system startup even occurs i.e before __init_sp();
#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 )in cstart.c is run
{
__init_sp();
}
Sep 07, 2020
04:33 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 07, 2020
04:33 PM
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?
Can you try changing PROCOND.RAMIN to 3 (no init) in UCB_DFlash and see if the behavior changes?
Attachments are accessible only for community members.
Sep 08, 2020
12:47 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 08, 2020
12:47 AM
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
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
Sep 09, 2020
03:38 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 09, 2020
03:38 AM
Hi,
Any update on this?
Any update on this?
Sep 09, 2020
04:50 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 09, 2020
04:50 AM
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?
Attachments are accessible only for community members.
Sep 09, 2020
05:00 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 09, 2020
05:00 AM
LSL File:
The Map file and source files used
// 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
Sep 09, 2020
05:29 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 09, 2020
05:29 AM
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...
Then have a look in the map file if your variables are added to this group...
Sep 09, 2020
06:38 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 09, 2020
06:38 AM
Your variables are part of the normal bss section and therefore initialized. Check what happens when you rename .bss.my_vars to .bss_myvars
Sep 09, 2020
06:39 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 09, 2020
06:39 AM
Hi I named the group "my_group" and it looks like the linker has added the variables to the correct group.
Again, the issue doesn't seem to be with linking the variables. While debugging, I can see them being written to without an errors.
Bit confused. What would you like me to do? Rename the select section?
+ 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?
Sep 09, 2020
09:10 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 09, 2020
09:10 AM
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.
Sep 10, 2020
06:25 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 10, 2020
06:25 AM
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
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
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
Aug 05, 2022
04:44 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 05, 2022
04:44 AM
Hi,
Anyone is there to explain how the variable is set to not initialize over resets?
Thank you
Babu Dudekula