Source volatile uint8_t mUsart0BufferReadPtr; void Usart0AtModeSkipLine(void) { uint8_t rdptr = 0; rdptr = mUsart0BufferReadPtr; rdptr = mUsart0BufferReadPtr; rdptr = mUsart0BufferReadPtr; } ------------- Generated asm +00000694: 93DF PUSH R29 Push register on stack +00000695: 93CF PUSH R28 Push register on stack +00000696: 920F PUSH R0 Push register on stack +00000697: B7CD IN R28,0x3D In from I/O location +00000698: B7DE IN R29,0x3E In from I/O location 179: uint8_t rdptr = 0; +00000699: 8219 STD Y+1,R1 Store indirect with displacement 181: rdptr = mUsart0BufferReadPtr; +0000069A: 91800000 LDS R24,0x0000 Load direct from data space +0000069C: 8389 STD Y+1,R24 Store indirect with displacement 182: rdptr = mUsart0BufferReadPtr; +0000069D: 91800264 LDS R24,0x0264 Load direct from data space +0000069F: 8389 STD Y+1,R24 Store indirect with displacement 183: rdptr = mUsart0BufferReadPtr; +000006A0: 91800264 LDS R24,0x0264 Load direct from data space +000006A2: 8389 STD Y+1,R24 Store indirect with displacement ------------------------ OS: WinXP gcc: avr-gcc.EXE (WinAVR 20100110) 4.3.3
I cannot reproduce the problem. Used this command line: avr-gcc -save-temps -O0 -mmcu=atmega164p -c test.c -o test.o Generated this assembly: .file "test.c" __SREG__ = 0x3f __SP_H__ = 0x3e __SP_L__ = 0x3d __CCP__ = 0x34 __tmp_reg__ = 0 __zero_reg__ = 1 .text .global Usart0AtModeSkipLine .type Usart0AtModeSkipLine, @function Usart0AtModeSkipLine: push r29 push r28 push __tmp_reg__ in r28,__SP_L__ in r29,__SP_H__ /* prologue: function */ /* frame size = 1 */ std Y+1,__zero_reg__ lds r24,mUsart0BufferReadPtr std Y+1,r24 lds r24,mUsart0BufferReadPtr std Y+1,r24 lds r24,mUsart0BufferReadPtr std Y+1,r24 /* epilogue start */ pop __tmp_reg__ pop r28 pop r29 ret .size Usart0AtModeSkipLine, .-Usart0AtModeSkipLine .comm mUsart0BufferReadPtr,1,1 .global __do_clear_bss and the object code disassembly was this: test.o: file format elf32-avr Disassembly of section .text: 00000000 <Usart0AtModeSkipLine>: 0: df 93 push r29 2: cf 93 push r28 4: 0f 92 push r0 6: cd b7 in r28, 0x3d ; 61 8: de b7 in r29, 0x3e ; 62 a: 19 82 std Y+1, r1 ; 0x01 c: 80 91 00 00 lds r24, 0x0000 10: 89 83 std Y+1, r24 ; 0x01 12: 80 91 00 00 lds r24, 0x0000 16: 89 83 std Y+1, r24 ; 0x01 18: 80 91 00 00 lds r24, 0x0000 1c: 89 83 std Y+1, r24 ; 0x01 1e: 0f 90 pop r0 20: cf 91 pop r28 22: df 91 pop r29 24: 08 95 ret So we need a complete test case, along with a command line that can reproduce the problem.
(In reply to comment #1) > I cannot reproduce the problem. > > c: 80 91 00 00 lds r24, 0x0000 Its mean load data from SRAM at address 0x0000. Variable (in our case mUsart0BufferReadPtr) has address not equal to zero. In my first post i use three equal strings rdptr = mUsart0BufferReadPtr; because first generated with error
(In reply to comment #2) > (In reply to comment #1) > > I cannot reproduce the problem. > > > > c: 80 91 00 00 lds r24, 0x0000 > > Its mean load data from SRAM at address 0x0000. Variable (in our case > mUsart0BufferReadPtr) has address not equal to zero. > > In my first post i use three equal strings > rdptr = mUsart0BufferReadPtr; I still cannot reproduce the error with the information that you've given me. You need to provide a test case that can reproduce the error. > because first generated with error >
> I still cannot reproduce the error you got >>lds r24, 0x0000 that is error! address of variable is NULL. Address of volatile uint8_t SomeVariable cant be NULL in any case. ---------- Data Memory Map for ATmega164P/324P/644P. 0x0000 - 0x001F - 32 Registers 0x0020 - 0x005F - 64 I/O Registers 0x0060 - 0x00FF - 160 Ext I/O Reg. 0x0100 - 0x04FF/0x08FF/0x10FF - Internal SRAM (1024/2048/4096 x 8)
(In reply to comment #4) > > I still cannot reproduce the error > you got > >>lds r24, 0x0000 > that is error! Take a look at the generated assembly. 3 accesses to the same variable. The disassembly shows 3 accesses to the same address. Please note that this disassembly is from the object code, not a final executable (before linking) because the test case you gave did not include a main() and therefore cannot be linked. Again, it is up to you, the bug reporter, to provide a compilable and linkable test case that can be reproduced to show the error.
Well, I will make necessary tests
Closing bug as WORKSFORME.