[Top][All Lists]

[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: Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4


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 
    57fa:       0c 94 75 34     jmp     0x68ea  ; 0x68ea 
    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



 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]