SRAM after Reset

[paulsmitton9]

Posted on September 23, 2008 at 06:50

SRAM after Reset

[paulsmitton9]

Posted on May 17, 2011 at 12:44

Can the contents of SRAM be guarenteed zeros after a Reset?

(in this case, reset after an rtc alarm to exit standby). I am using gcc and would like to avoid having to set .bss to zero, which is taking about six milliseconds! Cheers, Paul.

[16-32micros]

Posted on May 17, 2011 at 12:44Hi Paul, The contents of the SRAM is random after a power-off/power-on cycle of VDD/VDDA. Cheers, STOne-32.

[lanchon]

Posted on May 17, 2011 at 12:44

I bet you can mark the data you don't need initialized as persistent or something like that.

[disirio]

Posted on May 17, 2011 at 12:44

Is the BSS clearing code executed before or after the clock initialization ?

It is possible you can make it much faster by initializing the clock to high speed first (8 vs 72MHz). regards, Giovanni --- ChibiOS/RT

http://chibios.sourceforge.net

[paulsmitton9]

Posted on May 17, 2011 at 12:44

Thanks for confirming st-one, and your suggestions guys.

Raising the clock speed is a good idea, but i actually want it fast to save battery power (i.e. wake up every 100ms, scan adc, go back to sleep). Lanchon, i'll look into that, I don't think there is any standard section of memory that is uninitialised, but it may be possible to specify in the .map file. A possible alternative is declaring everything volatile, which could have a serious performance impact. However I have tried commenting this code out, and the only problem I have had, is with variables that I haven't initialised properly (and i tend to be careful about that), so perhaps ensuring proper initalisation (or using volatiles to initalise) would work.

[lanchon]

Posted on May 17, 2011 at 12:44

> A possible alternative is declaring everything volatile

I can't understand, how would that help?

[paulsmitton9]

Posted on May 17, 2011 at 12:44

>> A possible alternative is declaring everything volatile

> I can't understand, how would that help? I was thinking that if everything was volatile, the compiler would not assume anything was zero, even if it thought it had been initalised to zero. So whilst it could optimise out int x = 0 (since supposedly x was initalised 0 before main was called), it would not optimise volatile int x = 0 (since it could have changed since it's non-existant initalisation).

[paulsmitton9]

Posted on May 17, 2011 at 12:44

n.b. I tend to keep all of my variables within structs for tidyness, and partly out of habit since I do a bit of OO. So it is quite easy to write a procedure to cast each struct to a volitale array of bytes or words and and then write that to zero when the struct is first required (altough this hasn't seemed to be necessary yet).

void MemoryToZero(void* Address, u32 ByteCount) { while (ByteCount) ((vu8*)Address)[--ByteCount] = 0; }

[miles]

Posted on May 17, 2011 at 12:44

Quote:

void MemoryToZero(void* Address, u32 ByteCount) { while (ByteCount) ((vu8*)Address)[--ByteCount] = 0; } Are you familiar with ''memset''? It's part of libc.

http://www.iti.cs.tu-bs.de/cgi-bin/UNIXhelp/man-cgi?memset+3C

The nice thing about using standard functions in libc for things like memcpy, memset, etc., is that often the version in your C library is optimized for your processor. Like it might use SSE if you've got that, or Altivec, unroll loops, use duff's device, or be smart about the way your cache works. Not necessarily relevant for the STM32, but on processors that have a big speed difference between the core and main memory, it can be helpful. If you hand-optimize your own function, it can either use a feature that doesn't exist on a processor you want to port to, or may be very slow on the processor you want to port to.