Re: [avr-libc-dev] LPM instructions in optimized code causes unintended behavior in execution
Joerg Wunsch schreef: As Wouter van Gulik wrote: IMHO, the respective code is hand-crafted asm code in avr-libc. Are you sure? The code is about a jump table, is that in avr-libc? Errm, you are right... We should probably file a bug report at binutils as well. gas is excepting an 'illegal' instruction. This could mean gcc/gas also happily generates the undefined LD files? Thomas could you generate a minimum testcase? HTH, Wouter ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] LPM instructions in optimized code causes unintended behavior in execution
Wouter van Gulik schreef: Joerg Wunsch schreef: As Wouter van Gulik wrote: IMHO, the respective code is hand-crafted asm code in avr-libc. Are you sure? The code is about a jump table, is that in avr-libc? Errm, you are right... We should probably file a bug report at binutils as well. gas is excepting an 'illegal' instruction. This could mean gcc/gas also happily generates the undefined LD files? I meant instruction instead of files. No coffee yet... Wouter ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] LPM instructions in optimized code causes unintended behavior in execution
- Oorspronkelijk bericht - As Thomas Carsten Franke wrote: I did not restored the NVM CMD because I didn't know that it would has to be. This is correct. We recently added a note to the documentation in the header file avr/pgmspace.h telling that on Xmega devices, all the functions will only work as designed if NVM_CMD is set to 0x00 (NOP). As you had to manually take care to set NVM_CMD to something else before, I think it's only fair to leave the job to the programmer to restore it afterwards. Although true, I rather think this is a GCC bug. The avr instruction documentation says LPM R31, Z+ has undefined results. In the example it was oke to use LPM R31, Z. Since GCC does not know LPM, I think this might be easy to spot in the GCC code or relevant patch. Hth, Wouter ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] LPM instructions in optimized code causes unintended behavior in execution
On 17/06/10 10:15, Thomas Carsten Franke wrote: Am 17.06.2010 09:38, schrieb Wouter van Gulik: Wouter van Gulik schreef: Joerg Wunsch schreef: As Wouter van Gulik wrote: IMHO, the respective code is hand-crafted asm code in avr-libc. Are you sure? The code is about a jump table, is that in avr-libc? Errm, you are right... We should probably file a bug report at binutils as well. gas is excepting an 'illegal' instruction. This could mean gcc/gas also happily generates the undefined LD files? Just right now I added a problem report to gcc 4.3.3 version describing the problem. Just for the record the gcc bug id is:44564 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44564 I think this is a nasty bug, but it is hard to recreate the problem. I did a quick scan of GCC but I can't find a reference to a lpm r?, Z+ other than those to __temp_reg__. HTH, Wouter ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] LPM instructions in optimized code causes unintended behavior in execution
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 movwr30, r24
57f2: 31 97 sbiwr30, 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 subir30, 0x06 ; 6
5800: ff 4f sbcir31, 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: thomas-carsten.fra...@brunel.de
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 mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] LPM instructions in optimized code causes unintended behavior in execution
As Thomas Carsten Franke wrote: I did not restored the NVM CMD because I didn't know that it would has to be. This is correct. We recently added a note to the documentation in the header file avr/pgmspace.h telling that on Xmega devices, all the functions will only work as designed if NVM_CMD is set to 0x00 (NOP). As you had to manually take care to set NVM_CMD to something else before, I think it's only fair to leave the job to the programmer to restore it afterwards. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] LPM instructions in optimized code causes unintended behavior in execution
As Wouter van Gulik wrote: Although true, I rather think this is a GCC bug. The avr instruction documentation says LPM R31, Z+ has undefined results. In the example it was oke to use LPM R31, Z. IMHO, the respective code is hand-crafted asm code in avr-libc. Please file a bug report. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] LPM instructions in optimized code causes unintended behavior in execution
As Wouter van Gulik wrote: IMHO, the respective code is hand-crafted asm code in avr-libc. Are you sure? The code is about a jump table, is that in avr-libc? Errm, you are right... -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] LPM instructions in optimized code causes unintended behavior in execution
- Oorspronkelijk bericht - As Wouter van Gulik wrote: Although true, I rather think this is a GCC bug. The avr instruction documentation says LPM R31, Z+ has undefined results. In the example it was oke to use LPM R31, Z. IMHO, the respective code is hand-crafted asm code in avr-libc. Are you sure? The code is about a jump table, is that in avr-libc? Wouter ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
