AVR Freaks

Oh and another possible solution is sprintf_P() and PSTR() to keep all the strings in PROGMEM in the first place (which makes sense anyway)

Cliff

The stuff in init4 is 'naked' so is not a callable function. Basically the reset vector just jumps into it and when it completes it jumps into 'main'. So no chance of calling it a second time. From the .map file of a build you can see where it's coming from:

and from the .lss you can see what it does:

The problem with trying to duplicate this in C code are those hard coded 0x0060, 0x00A2 and 0x006C in there. You need to be able to access those hardcoded values symbolically - you can see how this is done in avr-libc by looking at the source of gcrt1.S:

http://cvs.savannah.gnu.org/view...

1) I think OP said previously that it's simply a requirement of his customer that it pass certain safety standards however pointless it may actually be

I really think that the "simple" answer here is positioning the routine into one of the .initN sections this will probably also involve making it "naked" and clearly the routine itself will not be able to rely on any pre-initialised global value or that any unitialised global contains 0x00. If it's placed before .init2 it couldn't even rely on SP being set or that R1 contains 0.

There's also a potential for "rug from under feet" problems if the compiler chooses to place any automatic locals on the stack rather than optimising them into register only usage!IN fact, for the same reason nothing in .data or .bss could be used anyway and I guess a lot of "register var asm("Rn")" is going to be needed to ensure the code really does just use machine registers.

Cliff

PS of course R00..R31 are really just RAM locations 0x0000..0x001F anyway! Are those part of the test too? If not, shouldn't they be, if they are then how on earth can they be tested?

Another alternative is to test the RAM one section at a time. If you know where the data you want to keep is located, you can save it in one of the sections that has already been tested and restore it when you're done.

Which was my previous point - use 'register' to bind local variables to registers (and check the .lss that it actually worked!). In that case you CAN ignore that warning from the manual - what it's warning you about are locals created on a stack frame when the function has no prologue to create a stack frame (and anyway you are going to wipe the stack memory so that couldn't work anyway). Like Curt says just use something like:

You don't even need a call to invoke sram_test() anywhere in the program. The very fact that it is 'naked' and in section '.init3' means that after the jmp from the reset vector the code will first pass through the stuff from the runtime library that disables interrupts, sets the stack pointer and puts 0 in R1. It will then fall into sram_test() in .init3 and (again because of 'naked') fall out of the bottom of it and into the code from the runtime in .init4 that does the _clear_bss, _copy_data things and that in turn will eventually fall into the "call main; jmp exit" stuff.

Cliff

The reason I mentioned asm("r16") / asm("r17") in the above rather than r4/r5 like you use is that LDI (and some other ops) can be used with R16 and above where it's more convoluted to do that kind of thing on the lower numbered registers. So you might want to move up to some of the later registers in that.

Cliff