AVR Freaks

actually, no; dont have notion of EESAVE (will check), but Im not re-downloading  between write and read, only turning off power, fully.

and I do get the read give same value as the write before turn off.

as usual I have in the other location when communicating, than where I have my setup, so cant make tests just now, but I will try

make a read direct on commandline, i.e not in terminal mode. 

Hi

Bootloader or ISP;  bit shorthand, do you refer to how I connect to M8 for Avrdude com; well that is actually a impayimpa of own make with RS232

(avrdude -c dapa ....) (has been working well for like 5yrs now, except some solering giving up now and then)

your "experience .." notion, evidently discards me as experienced :)  I have a strong feel that I have encountered this before (a while since i dumped eeprom)

Actually, storing worked once when whole code was in mainfile. Troube started whe I lifyed it to a separatly compiled file and .o file
(Coming to think of it)

Hi again.
I actually start thinking it could be a stack collission issue. avr-size givesme 517bytes in SRAM. Is there any way to check calling depth / stack alloc (think not checked, my code is some 10 at max)
as freeware (guess iccavr does the trick
.)

Well im using gnu

However I found an entry in a thread on the issue (of stack depth) from 09 where somone was encouraged to use (seemingly IAR) iccavr for checking (and yes I did realise it was a full sdk, didnt get it was iar though) anyways someone may have made afreeware hack ?, no.
Well I guess pen and paper to follow callchains isnt impossible..

Ok thanks
Though have still not understood if studio can debug when running on target ( how is communication done in that case)
Also it looks like its no good trying to use studio offline ?

Thanks ok
Its an atmega8 im working on.
Have no notion of deb support for this.
Guess ill have to make dummy rutines for my drivers and use simulator (/emulator)
Since they are at the end of call chain stack depth should be same

Ahh see ! I actually have 88s in store, bought as extras if mem would be too tight.
Looks I should mount a board with one.
How is deb accessed, hopefully uart or isp pins...

Hi again, havnt gotten to debug yet.

meanwhile Im digging into asm somewhat;

I have some things I dont really understand:

    25a:	08 d9       	rcall	.-3568   	; 0xfffff46c <__eeprom_end+0xff7ef464>

     4ea:	df 93       	push	r29
     4ec:	cf 93       	push	r28
     4ee:	00 d0       	rcall	.+0      	; 0x4f0 <logg_rec_get+0x24>
     4f0:	00 d0       	rcall	.+0      	; 0x4f2 <logg_rec_get+0x26>

these are two snippets from the .lst

1. the addressing beyond .eeprom_end ?? what is meant ...  ( it seems to be associated with calls to AVR-lib routine itoa / ltoa...

2. then, whats the use of putting the address of current (!) rutine onto stack TWICE,  just in order to do 4 extra POPs at the end..

   (this is at the routine entry when saving registers / PUSHing )

/g

HIllarious, I like these machines,esp. the m8, its so, well most of the time, straight forward (but this is of cause gnu and not atmel...)

Yes! right on. I have two 32bits vars in EEprom, and they are missbehaving when I link the total assembly, but while running "cut out" testprograms, alls is fine.

Errors are also "shifting" meaning that i can do one first occurance of my UART command to set clock  (which is a totally different branch from the EEstorage)

first time it fails, repeated exacct same it goes to the D1302 and sets the clock. (works perfect in clock test, or rather when removing routines using EE,

which is code to handle HX711 adc for a weight-scale-sensor). The two stored values that dont get EEstored, in the assembled version are tare and calibration

(two 32bitters), while well and all stored when linking test prog for only that part.