Is this a BUG??...avrstudio help...

[kanishka13]

m32def.inc

I had written a basic program to STORE data in SRAM and compiled it with the data memory window open. The result was as expected. The data from a register was STORED into the SRAM location. The program was as below....

;Program to store data into SRAM location 0x60

.include "m32def.inc"
.org 0x000
rjmp STORE
STORE:
ldi r16,10
sts 0x60,r16 ;store direct into SRAM
rjmp STORE


But then...

I had written another program to load the contents at 0x60 location of SRAM to R16. I had recompiled the new program. Logic says that since i've rebuild the whole program again the previous contents of the SRAM must be lost and the value loaded into the R16 register must be FF.

Program to load data from SRAM and store it in R16

.include "m32def.inc"
.org 0x000
rjmp LOAD
LOAD:
lds r16,0x60 ;load direct from SRAM
rjmp LOAD

But the value that had been stored by the previous program was loaded....So isint this a BUG?? :?::!:

Or am I wrong somewhere??....:?::?:

I had used AVRSTUDIO 4.0 with SP1 for atmega32.

 

[ctownsend]

try this:

.include "m32def.inc"
.org 0x000

	rjmp start

Start:
;always set up stack pointer!
;
	ldi	r16,LOW(RAMEND)	  ;set up stack pointer low
	out	SPL,r16
	ldi	r16,HIGH(RAMEND)  ;set up stack pointer high
	out	SPH,r16

	clr r16            ;start with 0 value in r16

main:
	rcall	store       ;store data in Ram @0x60 from r16
	rcall	load        ;load byte from Ram @0x60 into r17
	rjmp	main        ;loop

STORE:
	inc	r16           ;every time inc r16
	sts 0x60,r16        ;store direct into SRAM from r16
	ret

LOAD:
	lds r17,0x60        ;load direct from SRAM into r17
	ret 

.exit

Are you using the simulator to check the values of 0x60, and r16?
Single step through the program using F11 and view the upper registers (r16, r17) and the ram, you will see the changes in every step.

Check this code out, it works. Every time the loop occurs, the value of 0x60 will increase by 1.

Good Luck

 

[kanishka13]

yes i am using the avr simulator to view the SRAM memory

 

[ctownsend]

This one uses the Y registers as a pointer to Ram.

.include "m32def.inc"
.org 0x000
	rjmp start


Start:
;always set up stack pointer!
;
	ldi	r16,LOW(RAMEND)	  ;set up stack pointer low
	out	SPL,r16
	ldi	r16,HIGH(RAMEND)  ;set up stack pointer high
	out	SPH,r16
	
main:
	rcall	clrRam		;clear Ram to 0100
	rcall	fillRam		;fill ram to 0100
	rjmp	main        ;loop

clrRam:
	ldi	r16,0xFF    ;fill ram with value 0xFF
	ldi YL, 0x60        ;start of ram
    ldi YH, 0x00           ;
clrRam1: 
	st	Y+,r16           ;store data in r16 @Y
				     ;and increment Y
	cpi	YH,0x01         ;clear Ram to 0100
	brne	clrRam1
	ret
;------------------------------------------
;fill ram with values 00,01,02,03,04,etc...
FillRam:
	clr r16				;start with 0 value in r16
	ldi YL, 0x60                  ;start of ram
        ldi YH, 0x00                 ;
FillRam1: 
	st	Y+,r16                ;store data in r16 @Y
					  ;and increment Y
	inc	r16			;add 1 to r16
	cpi	 YH,0x01            ;Fill Ram to 0100
	brne FillRam1
	ret
.exit

You can bulk step the code in the simulator. Position the cursor where you want it to stop, then just select debug, run to cursor (while the simulator is running).

Good Luck

 

[laktronics]

Hi,
This is only a general comment. I do not think that the particular behaviour need be considered as a bug since you are directly reading an SRAM location and the software will simply read it. It also shows that the software does not initialise these locations and you have to do it through software if required. You may get some other value at this location if you run the software immediately after power is applied.
If you used a variable name to store the value, may be the software would have autoinitiated to FFh or 00h for the first time usage. Again it can depend upn the conventions followed in a Language.
Regards,
Laktronics