| Author |
Message |
|
|
Posted: Jul 20, 2012 - 08:30 AM |
|

Joined: Jul 26, 2010
Posts: 3
|
|
A simple question: what happens with RAM memory content during standard SPI programming ("Serial Downloading")? The datasheet says:
Quote:
The Chip Erase operation turns the content of every memory location in both the Program and EEPROM arrays into 0xFF.
But experiments show that both STK500 and usbasp programming erases (resets) RAM. If this operation is included in Chip Erase, then why it is kept silent? I use ATmega88PA RAM for RTC, it cannot be erased by a simple reset. |
|
|
| |
|
|
|
|
|
Posted: Jul 20, 2012 - 09:17 AM |
|

Joined: Feb 12, 2005
Posts: 16296
Location: Wormshill, England
|
|
No. The AVR does not clear the SRAM by itself.
Look in your data sheet. SFRs have a defined state. SRAM will have a random state.
With a C program the "crts.o" ( C RunTime Startup Object ) does various things before your main() function is called. e.g. initialise your data section, clear the BSS section, initialise stack pointer, ...
If you use ASM, you need to do this yourself.
If your AVR is programmed with a Chip Erase, and a test ASM program, you can see what happens to SRAM. I guess that the SRAM contents will remain unchanged from their initial power-up random values.
If it worries you, try it for yourself. Even if the Chip Erase was to set a defined state of SRAM, do you really want to re-program the flash every time you power-up the board?
David. |
|
|
| |
|
|
|
|
|
Posted: Jul 20, 2012 - 09:29 AM |
|


Joined: Oct 30, 2002
Posts: 5720
Location: The Netherlands
|
|
I guess the OP doesn't want his sw-RTC to be reset when his widget gets the occasional firmware update?
Could be tackled by first backing then up into EEPROM, flash the MCU, then reset from the EEPROM copy. You could even measure how long flashing actually takes and adjust for that. |
|
|
| |
|
|
|
|
|
Posted: Jul 20, 2012 - 10:01 AM |
|

Joined: Feb 12, 2005
Posts: 16296
Location: Wormshill, England
|
|
You alter the "startup.s" or "startup.asm" or whatever your "crts.S" is called on your Compiler / system. Reserve a section of SRAM that does not get cleared.
If you use avr-gcc, you can simply put your RTCC variables in the .noinit section. i.e. no need to edit crts.S. So your RTCC will survive a RESET. Probably a re-flashing of your firmware too.
Note that you will 'lose' time while the AVR is in reset / flashing.
David. |
|
|
| |
|
|
|
|
|
Posted: Jul 20, 2012 - 10:50 AM |
|

Joined: Jul 26, 2010
Posts: 3
|
|
David, please read my post again
Quote:
I use RAM for RTC, it cannot be erased by a simple reset.
No, it is not initialization issue, variables retain values after reset, power-on etc. but not after serial programming. |
|
|
| |
|
|
|
|
|
Posted: Jul 20, 2012 - 10:55 AM |
|


Joined: Jul 18, 2005
Posts: 62281
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
| What is doing the serial programming? It'd only be if it actually disconnected Vcc to the chip for some considerable time that SRAM would change. AVRs are static CMOS and even small amounts of residual capacitance in the circuit will likely keep SRAM "alive" for several seconds even in the absence of power. |
_________________
|
| |
|
|
|
|
|
Posted: Jul 20, 2012 - 11:22 AM |
|

Joined: Jul 26, 2010
Posts: 3
|
|
| I thought about that but Vcc is stable during programming. |
|
|
| |
|
|
|
|
|
Posted: Jul 20, 2012 - 11:35 AM |
|

Joined: Feb 12, 2005
Posts: 16296
Location: Wormshill, England
|
|
|
Cubrilo wrote:
David, please read my post again
Quote:
I use RAM for RTC, it cannot be erased by a simple reset.
No, it is not initialization issue, variables retain values after reset, power-on etc. but not after serial programming.
Are you saying that .noinit can retain RAM during power-down ?
I am only guessing that SRAM is unchanged by serial programming.
Please describe your exact situation.
I will try it myself if you can describe something reproducible.
David. |
|
|
| |
|
|
|
|
|