Ram and registers values after reset

Hi all

If a sketch is running and I activate reset, does Ram and registers R0 - R31 maintain whatever value was in them before the reset? The only thing I could find in the datasheet that was related:

During reset, all I/O Registers are set to their initial values, and the program starts execution from the Reset Vector.

Perhaps I missed something.

No they don't - they will be set to whatever your sketch sets them up to do as it starts. The only thing you can count on being in place is the Flash memory and whatever had been written to EEPROM (assuming 3.3mS were elapsed after the EEPROM write started and before the reset occurred).

CrossRoads: No they don't - they will be set to whatever your sketch sets them up to do as it starts.

What I meant was, after the reset, the AVR will start execution at offset 0x0000 where there will be a jump to the beginning of the actual code, so assuming that before I reset, I put the value of say 0xAA into ram address 0x100 and the sketch does not write to this ram address until told to, surely the original value should still be there. Likewise with a register. Is my thinking correct? Sorry if my initial explanation was a bit vague.

Ten seconds with google:

http://support.atmel.com/bin/customer.exe?=&action=viewKbEntry&id=959

The problem with Google is what exactly to enter as the search criteria. Anyway, thank you that answers my question.

I typed "avr ram after reset" - nothing cryptic there.

Thank you

UnoDueTre: What I meant was, after the reset, the AVR will start execution at offset 0x0000 where there will be a jump to the beginning of the actual code, so assuming that before I reset, I put the value of say 0xAA into ram address 0x100 and the sketch does not write to this ram address until told to, surely the original value should still be there.

"before I reset"? Will you be able to tell the different between a reset caused by power-up and a reset caused by something else?

http://forum.arduino.cc/index.php/topic,56809.0.html

[quote author=Coding Badly link=topic=200110.msg1475895#msg1475895 date=1384975038]

UnoDueTre: What I meant was, after the reset, the AVR will start execution at offset 0x0000 where there will be a jump to the beginning of the actual code, so assuming that before I reset, I put the value of say 0xAA into ram address 0x100 and the sketch does not write to this ram address until told to, surely the original value should still be there.

"before I reset"? Will you be able to tell the different between a reset caused by power-up and a reset caused by something else?

[/quote]

When the sketch (re)starts, it checks a certain ram location or general purpose register for a certain value, if not there then I can assume that it was not reset but rather power cycled. On the other hand if the value is there, then it was reset (warm boot) versus a cold boot.

UnoDueTre: When the sketch (re)starts, it checks a certain ram location or general purpose register for a certain value, if not there then I can assume that it was not reset but rather power cycled.

You assume ram / registers are initialized at power-up. Are they?

How do the activities of the bootloader affect your plan? The C run-time library?

From Section 8.3: 8.3 SRAM Data Memory Figure 8-3 shows how the ATmega48A/PA/88A/PA/168A/PA/328/P SRAM Memory is organized. The ATmega48A/PA/88A/PA/168A/PA/328/P is a complex microcontroller with more peripheral units than can be supported within the 64 locations reserved in the Opcode for the IN and OUT instructions. For the Extended I/O space from 0x60 - 0xFF in SRAM, only the ST/STS/STD and LD/LDS/LDD instructions can be used. The lower 768/1280/1280/2303 data memory locations address both the Register File, the I/O memory, Extended I/O memory, and the internal data SRAM. The first 32 locations address the Register File, the next 64 location the standard I/O memory, then 160 locations of Extended I/O memory, and the next 512/1024/1024/2048 locations address the internal data SRAM. The five different addressing modes for the data memory cover: Direct, Indirect with Displacement, Indirect, Indirect with Pre-decrement, and Indirect with Post-increment. In the Register File, registers R26 to R31 feature the indirect addressing pointer registers. The direct addressing reaches the entire data space. The Indirect with Displacement mode reaches 63 address locations from the base address given by the Y- or Zregister. When using register indirect addressing modes with automatic pre-decrement and post-increment, the address registers X, Y, and Z are decremented or incremented. The 32 general purpose working registers, 64 I/O Registers, 160 Extended I/O Registers, and the 512/1024/1024/2048 bytes of internal data SRAM in the ATmega48A/PA/88A/PA/168A/PA/328/P are all accessible through all these addressing modes. The Register File is described in ”General Purpose Register File” on page 10.

I can't tell you whether data you write to one of the higher SRAM locations, if you can even control where that location is, is going to be usable or not after a non-power loss reset.

[quote author=Coding Badly link=topic=200110.msg1475960#msg1475960 date=1384977505] You assume ram / registers are initialized at power-up. Are they? [/quote]

Nope.

[quote author=Coding Badly link=topic=200110.msg1475960#msg1475960 date=1384977505] How do the activities of the bootloader affect your plan? The C run-time library? [/quote]

The bootloader could wreck them. I assume you'd erase it

[quote author=Coding Badly link=topic=200110.msg1475960#msg1475960 date=1384977505]

UnoDueTre: When the sketch (re)starts, it checks a certain ram location or general purpose register for a certain value, if not there then I can assume that it was not reset but rather power cycled.

You assume ram / registers are initialized at power-up. Are they? [/quote]

I agree they are not initialized but having said that, what are the chances they will contain the exact value I'm looking for? (especially a value of 0xAA).

How do the activities of the bootloader affect your plan? The C run-time library?

The bootloader may get in the way if used, I don't know but not worried as I don't use one. As regards the run-time libs, I assume you are referring to one having little to no control as to how it will use ram and registers? My thinking here as follows: As opposed to a compiled executable on a PC where variable storage in ram will be dynamic based on many things and certainly will not be at the same address if a program is closed and re-opened, on the AVR it's "hardcoded" so to speak once the sketch is compiled and uploaded to the AVR, so surely it would be a case of checking that variables value using perhaps strcpy_P? Or is my thinking completely off? I will test by compiling a simple sketch to do just that and debug in AVR Studio.

UnoDueTre: As opposed to a compiled executable on a PC where variable storage in ram will be dynamic based on many things and certainly will not be at the same address if a program is closed and re-opened, on the AVR it's "hardcoded"...

Which is even more troublesome. You are now dependent on specific versions of the toolset and the run-time behaviour of your program. A small change to either could leave you in a position where the memory location is used by two independent pieces of code.

You have yet to make any argument against the EEPROM.

[quote author=Coding Badly link=topic=200110.msg1476066#msg1476066 date=1384981925]

UnoDueTre: As opposed to a compiled executable on a PC where variable storage in ram will be dynamic based on many things and certainly will not be at the same address if a program is closed and re-opened, on the AVR it's "hardcoded"...

Which is even more troublesome. You are now dependent on specific versions of the toolset and the run-time behaviour of your program. A small change to either could leave you in a position where the memory location is used by two independent pieces of code. [/quote]

Yes I would be at the mercy of the toolset but since this is a specialized one off, not too worried. As regards the run time behaviour of my pgm, I can also ensure that the variables memory position is not over written. What I have found is that the compiler is very linear in it's allocation of ram addresses for variables. I defined a few variables before setup() and found that it pretty much starts allocating addresses at begining of ram. So if I declare 2 floats then my "check" variable as a byte, the "check" variable will be at offset 9, if I declare 2 floats, an int then the "check" byte, it will be at offset 11 and so on.

You have yet to make any argument against the EEPROM.

Limited number of writes.

I didn't see this said directly, but on startup, the c runtime will set up the global data section. Any variables not expressly initialized will be set to zero. Therefore, you would need to make sure that your test variable is not in the global data section.

UnoDueTre: What I have found is that the compiler is very linear in it's allocation of ram addresses for variables. I defined a few variables before setup() and found that it pretty much starts allocating addresses at begining of ram. So if I declare 2 floats then my "check" variable as a byte, the "check" variable will be at offset 9, if I declare 2 floats, an int then the "check" byte, it will be at offset 11 and so on.

Why do I bother. You clearly did not follow the link I posted.

[quote author=Coding Badly link=topic=200110.msg1476281#msg1476281 date=1384995224]

Why do I bother. You clearly did not follow the link I posted.

[/quote]

Actually I did. I will finish the sketch and post here to illustrate what I mean.

UnoDueTre:
Hi all

If a sketch is running and I activate reset, does Ram and registers R0 - R31 maintain whatever value was in them before the reset?

Hi, I know this is an old topic but I found it when I was looking for the same thing. I have found no definite answer so I did a short test. On ATTiny13A r17 persists Watchdog reset so I concluded all general purpose registers (and the RAM ofc.) are not cleared and stay the same after reset. There is the test code:

.def temp = r16
.def test = r17

	inc test
	out PORTB, test
	wdr
	ldi temp, (1<<WDCE)+(1<<WDE)
	out WDTCR, temp
	ldi temp, (1<<WDE)+(1<<WDP2)+(1<<WDP0)	;about 0.5 s timeout
	out WDTCR, temp
end:
	rjmp end