AURIX™ Forum Discussions

[User16898]

Hi,
Currently I'm using standby mode in my application, I have several configurable variables I set during run time.
my init for those variables looks like this:

trigger.c

trigger my_trigger ={
		{.code = my_code,
		 .trigger_position = TRIGGER_DISABLED,
		 .trigger_enabled = TRUE,
},

During runtime I'm changing trigger_enabled property. Then I enter sleep state in which I supply DSPR0 RAM:

pspram_sequnece.c 
        IfxScuWdt_clearSafetyEndinitInline(password);
	IfxScuWdt_clearCpuEndinitInline(wdt,cpu_password);
	Ifx_SCU_PMSWCR0 pms_0_config  = scu->PMSWCR0;
	while(SCU_PMSWCR0.B.LCK);

	pms_0_config.B.STBYRAMSEL = 1;

	pms_0_config.B.ESR1WKEN = 1;
	pms_0_config.B.ESR1DFEN = 1;
	pms_0_config.B.ESR1EDCON = falling_edge;

	pms_0_config.B.PINAWKEN = 1;
	pms_0_config.B.PINADFEN = 1;
	pms_0_config.B.PINAEDCON = falling_edge;

	pms_0_config.B.PINBWKEN = 1;
	pms_0_config.B.PINBDFEN = 1;
	pms_0_config.B.PINBEDCON = falling_edge;

	pms_0_config.B.WUTWKEN = 1;

	scu->PMSWCR0 =  pms_0_config;
	while(SCU_PMSWCR0.B.LCK);
	IfxScuWdt_clearCpuEndinitInline(wdt,cpu_password);
	IfxScuWdt_clearSafetyEndinitInline(password);

Data sheet says:

STBYRAMSEL bit in PMSWCR0:
[18:17] rw Standby RAM supply in Standby Mode
00B Standby RAM is not supplied.
01B Standby RAM (CPU0 DSPR) is supplied.
Note: All other bit combinations are reserved. Incase
Standby RAM supply is activated, Standby RAM
is not initialised after wakeup or PORST
irrespective of configuration

So i assume that my custom configured data should not be changed after wake-up.
The problem is that after wake up all my configured data return to it's initial values (like in trigger.c).
i make sure that that I'm not reseting this values at startup.
It looks like standby ram is re initializing during wake-up.

what could pose a problem here ?

I work on TC222L

[cwunder]

By default the compiler will clear all uninitialized data to zero. Have you declared these variables so that they are not cleared by the compiler startup software (clear table)?

[User16898]

No, how to do it ?

[cwunder]

It depends on the toolchain you are using.

For Tasking they have a #pragma noclear
For Hightec I am not aware of a pragma but you can create a data section the is not part of the clear_table or copy_table.

[User13836]

For the TASKING tools #pragma noclear is only applicable to sections which are not initialized. Those sections will be cleared by default since this is an ISO C requirement. When #pragma noclear is used the _c_init function called by the C startup code won't zero the RAM variable anymore.

But from what I understood you are using initialized data:

trigger my_trigger ={
{.code = my_code,
.trigger_position = TRIGGER_DISABLED,
.trigger_enabled = TRUE,
},

This will be initialized by the _c_init function which is called by the C startup code. What happens in your wakeup stage? Is this a kind of software reset? So the application starts to run from the reset vector? Or is it supposed to continue from the code where it entered the sleep mode? Your description is for a behavior which is like when the application starts from scratch after wakeup. Then you cannot prevent that the variable is initialized with the default value because the C startup code is executed.

Best regards,
Ulrich Kloidt

TASKING tools support

[cwunder]

To further add to Ulrich's comments.

"Sleep" or "Standby" are two different power modes of AURIX. Your title and description indicates you are going to Standby mode so here are my comments to Standby mode.

When you use AURIX in Standby mode the device only uses its internal EVR Pre-regulator for power. Consequently only the Standby RAM (if enabled) and part of the PMC are keep powered everything else is not powered. When the device recognizes a wake event you do not start at the next instruction where you entered Standby. The Infineon SSW will always run and the user code will always begin at the start address specified by the BMHDx. Your software needs to examine the contents of the RSTSTAT and PMSWSTAT registers to determine your actions (software flow for a Reset event or Standby wake event).

Any data that you want to keep in the Standby RAM should be explicitly initialized by your software such that on a reset event you initialize it but on a Standby wake event you do not (unless the RSTSTAT.STBYR is set).

Note: Waking up from Standby is essentially a "soft" reset as you will need to initialize your system again.
Note: "A power fail event of the Standby supply during Standby mode will inevitably result in the loss of Standby RAM contents. Consequently, a cold PORST event is issued and the Standby domain is set into reset. EVR Pre- regulator under-voltage violation is indicated in RSTSTAT.STBYR flag."