[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[avr-libc-dev] LPM instructions in optimized code causes unintended beha
From: |
Thomas Carsten Franke |
Subject: |
[avr-libc-dev] LPM instructions in optimized code causes unintended behavior in execution |
Date: |
Wed, 16 Jun 2010 18:44:32 +0200 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 |
Hi,
I went into a strange situation in xmega128 project after reading from
signature or calibration row. I used the pgm_read_byte functions after
setting the NVM command accordingly. Both I did with disabled interrupts
to prevent any disturbing. I did not restored the NVM CMD because I
didn't know that it would has to be. All my functions set it before
usage of NVM controller.
Strange behavior grow up e.g. damaging my memory data or causing reset -
all in optimized compilation -O1 .. -Os only.
I thing I have found the reason but I'm not sure - maybe s.o. can help.
I searched the assembled code and found an additional LPM command
somwhere in code in optimized version:
switch (cmdGroup)
57ec: 85 2d mov r24, r5
57ee: 90 e0 ldi r25, 0x00 ; 0
57f0: fc 01 movw r30, r24
57f2: 31 97 sbiw r30, 0x01 ; 1
57f4: e2 31 cpi r30, 0x12 ; 18
57f6: f1 05 cpc r31, r1
57f8: 10 f0 brcs .+4 ; 0x57fe
<cmdExec_executeCommand+0x88>
57fa: 0c 94 75 34 jmp 0x68ea ; 0x68ea
<cmdExec_executeCommand+0x1174>
57fe: e6 50 subi r30, 0x06 ; 6
5800: ff 4f sbci r31, 0xFF ; 255
5802: ee 0f add r30, r30
5804: ff 1f adc r31, r31
5806: 05 90 lpm r0, Z+
5808: f4 91 lpm r31, Z+
580a: e0 2d mov r30, r0
580c: 19 94 eijmp
{
case AL_CMD_GROUP_GEN:
It seems that the compiler reads a jump address from program memory -
uses Z pointing to the PGM-address and reads the jump address in Z back
or so - looks strange but seems to work - IF and ONLY IF the NVM CMD is
equal to NVM_CMD_NO_OPERATION_gc(read flash).
But does not work if NVM CMD is e.g. NVM_CMD_READ_CALIB_ROW_gc. In this
case the jump address seems to be read from calibration row which makes
no sense from my point of view. Does the compiler not set the NVM CMD
before such generating such code out of a switch statement?
Hopefully s.o. can clarify or confirm the behavior. If so - I found my
problem, else I have to hope that there is no other hidden reason in my
code.
Thanks
Thomas
--
Mit freundlichen Grüßen
Brunel GmbH
Dipl.-Inf. Thomas Carsten Franke
- Senior Software Designer -
Brunel GmbH
Bereich Communications
Daimlerring 9
31135 Hildesheim
Tel. +49 5121 1760-820
Fax: +49 5121 1760-999
E-Mail: address@hidden
Internet: www.brunel.de
Hauptsitz: Airport City, Hermann-Köhl-Str. 1, 28199 Bremen
Amtsgericht Bremen HRB 16935
General Manager: Johan Arie van Barneveld
- [avr-libc-dev] LPM instructions in optimized code causes unintended behavior in execution,
Thomas Carsten Franke <=
- Re: [avr-libc-dev] LPM instructions in optimized code causes unintended behavior in execution, Joerg Wunsch, 2010/06/16
- Re: [avr-libc-dev] LPM instructions in optimized code causes unintended behavior in execution, Wouter van Gulik, 2010/06/17
- Re: [avr-libc-dev] LPM instructions in optimized code causes unintended behavior in execution, Joerg Wunsch, 2010/06/16
- Re: [avr-libc-dev] LPM instructions in optimized code causes unintended behavior in execution, Wouter van Gulik, 2010/06/16
- Re: [avr-libc-dev] LPM instructions in optimized code causes unintended behavior in execution, Joerg Wunsch, 2010/06/16
- Re: [avr-libc-dev] LPM instructions in optimized code causes unintended behavior in execution, Wouter van Gulik, 2010/06/17
- Re: [avr-libc-dev] LPM instructions in optimized code causes unintended behavior in execution, Wouter van Gulik, 2010/06/17
- Re: [avr-libc-dev] LPM instructions in optimized code causes unintended behavior in execution, Thomas Carsten Franke, 2010/06/17
- Re: [avr-libc-dev] LPM instructions in optimized code causes unintended behavior in execution, Wouter van Gulik, 2010/06/17
- RE: [avr-libc-dev] LPM instructionsin optimized code causes unintended behavior in execution, Weddington, Eric, 2010/06/17