[Bug other/44940] New: XMEGA RAMPZ Initialization
When compiling a bootloader for the XMEGA128 (starting address 0x2), RAMPZ is initialized to 2 in the __do_copy_data section. This has the effect that any indirect register access will fail. For example the following code extract will result in the register NOT being set to 0xCB when RAMPZ = 2. 20c6e: 2b ec ldi r18, 0xCB ; 203 20c70: e0 e5 ldi r30, 0x50 ; 80 20c72: f0 e0 ldi r31, 0x00 ; 0 20c74: 22 83 std Z+2, r18; 0x02 To recreate this, simply put OSC.XOSCCTRL = 0xCB; in the main function and link to bootloader memory space. -- Summary: XMEGA RAMPZ Initialization Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: darkdragon2000 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44940
[Bug target/45264] New: Stack corruption with any function using frame
With the beta AVR toolchain 3.0.0.207, the prologue for functions using a frame has changed and is now causing stack corruption when an interrupt fires. Take for example a function which needs 5 bytes of frame. This is how the frame is setup in the function prologue: Under WinAVR2010: a30: df 93 pushr29 a32: cf 93 pushr28 a34: 00 d0 rcall .+0 ; 0xa36 a36: 00 d0 rcall .+0 ; 0xa38 a38: 0f 92 pushr0 a3a: cd b7 in r28, 0x3d ; 61 a3c: de b7 in r29, 0x3e ; 62 AVR Toolchain 3.0.0.207: +0507: 93DFPUSH R29Push register on stack +0508: 93CFPUSH R28Push register on stack +0509: B7CDINR28,0x3D In from I/O location +050A: B7DEINR29,0x3E In from I/O location +050B: 9725SBIW R28,0x05 Subtract immediate from word +050C: BFDEOUT 0x3E,R29 Out to I/O location +050D: BFCDOUT 0x3D,R28 The stack corruption occurs when an interrupt fires between addresses 0x50C and 0x50D in the example above since the stack pointer is only half updated. I have submitted this as critical since it causes applications to crash consistently. -- Summary: Stack corruption with any function using frame Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: critical Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: darkdragon2000 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45264
[Bug target/45264] Stack corruption with any function using frame
--- Comment #2 from darkdragon2000 at hotmail dot com 2010-08-12 17:52 --- It's not a bug in the handler since when the interrupt fires at the point when the stack pointer is invalid (right after 0x50c), the program counter gets pushed onto the stack, which is an invalid location. When I tried to submit a report with the vendor, they pointed me back here. Maybe this should go to AVRLiBC? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45264
[Bug target/45264] Stack corruption with any function using frame
--- Comment #3 from darkdragon2000 at hotmail dot com 2010-08-12 23:56 --- Created an attachment (id=21472) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21472&action=view) File which recreates the issue -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45264
[Bug target/45264] Stack corruption with any function using frame
--- Comment #4 from darkdragon2000 at hotmail dot com 2010-08-12 23:56 --- Created an attachment (id=21473) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21473&action=view) makefile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45264
[Bug target/45264] Stack corruption with any function using frame
--- Comment #6 from darkdragon2000 at hotmail dot com 2010-08-13 22:30 --- OK thanks, is the code I attached here OK? I already submitted this to Atmel also (#605725). Last time I submitted a bug to them this is the reply I got back: Note that avr-gcc and avr-libC are open-source projects, which you may directly report bugs to (see http://www.nongnu.org/avr-libc/bugs.html). (In reply to comment #5) > Marking this bug as INVALID because the AVR Toolchain 3.0.0.207 is not an > officially released toolchain, and only in beta. > > If you have any potential bugs, then please send to avr AT atmel DOT com, and > please CC me. AFAIK, Atmel did not (or should have not) sent you to here. > > When you do send a bug report, send a compilable test case that shows the bugs > along with the command line you used, and especially show which device this is > for. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45264