Is RAM data always been cleared after software reset on DJ64

[Karen]

I use 9S12DJ64 on my project. I use the following code to force the software reset / reboot:

code:

swReset()

{

     COPCTL = 0x01;

    ARMCOP = 0x98;

} 

I wonder that after the reboot, will data RAM be cleared or still be able to keep the value stored before the reboot. In other words, if a global variable is assigned to a non-zero value, will that global variable be cleared to zero after the software reboot? I noticed that the global variables are always reset to zero on my code after the software reboot. I would like to know if it is correct behavior or something was wrong on my code or the way of reboot I implemented. Cosmic C compiler is used in my company. I contacted the technical support at Cosmic and I was told there was no way ( no such assembler command) to simply reset program counter to zero (like "jmp $0") to reset DJ64. Is it true? Very appreciate for your help!  

Thanks.

Karen Shi

[JimDon]

The mcu itself leaves ram alone.
Well, you wouldn't want to jump to 0 anyway, but the problem with jumping to the reset vector is that the rest of the processor is not reset.

Whats more you would still end up going thru the "C" runtime start up code.
The "C" run time start up will set global variables to there declared initial values.
If no initial value is given they are set to 0 by default.
It is the "C" run time that calls main.

The way to handle this could be to exclude a section of ram so that the complier and linker will not put anything there, then set a pointer to it. I don't use Cosmic, so I can't tell you how. If you used CW, you could adjust the PRM file for this. This section of ram will then not be set by the start up code.

[Lundin]

In addition, if you simply wish to reset the MCU from software, then write an incorrect value to the COP registers. The COP must be active for this to work.

This is useful if you want to preserve values after a reset. After a COP reset, you can still trust the variable values (although I'd recommend to use checksum on them). But after a power on / power loss reset, you can't trust the values. The S12 has the possibility to yield different startup interrupts depending on if the reset was caused by the COP or power loss.