sorry ! it was a mistake

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sorry ! it was a mistake

Last Edited: Fri. Apr 21, 2017 - 09:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jodis188 wrote:
Sometimes compiler can create bad vectors :
Are you suggesting iox128a1u.h is at fault then?

C:\SysGCC\avr\avr\include\avr>grep _VECTOR(2 iox128a1u.h
#define PORTC_INT0_vect      _VECTOR(2)  /* External Interrupt 0 */
#define TCC1_OVF_vect      _VECTOR(20)  /* Overflow Interrupt */
#define TCC1_ERR_vect      _VECTOR(21)  /* Error Interrupt */
#define TCC1_CCA_vect      _VECTOR(22)  /* Compare or Capture A Interrupt */
#define TCC1_CCB_vect      _VECTOR(23)  /* Compare or Capture B Interrupt */
#define SPIC_INT_vect      _VECTOR(24)  /* SPI Interrupt */
#define USARTC0_RXC_vect      _VECTOR(25)  /* Reception Complete Interrupt */
#define USARTC0_DRE_vect      _VECTOR(26)  /* Data Register Empty Interrupt */
#define USARTC0_TXC_vect      _VECTOR(27)  /* Transmission Complete Interrupt */
#define USARTC1_RXC_vect      _VECTOR(28)  /* Reception Complete Interrupt */
#define USARTC1_DRE_vect      _VECTOR(29)  /* Data Register Empty Interrupt */

There is little doubt that when this is used it will create __vector_22 and not __vector_20

 

Do you either (a) have an old/faulty header file for the device or (b) did you build for the wrong target

 

Here is the very simplest of examples built with avr-gcc 5.4.0:

C:\SysGCC\avr\avr\include\avr>type int.s
#define __SFR_OFFSET 0
#include <avr/io.h>

.global main
main:
        rjmp    main

.global TCC1_CCA_vect
TCC1_CCA_vect:
        push    r24
        ldi             r24, 1
        sts             PORTR_OUTTGL, r24
        pop             r24
        reti
C:\SysGCC\avr\avr\include\avr>avr-gcc -x assembler-with-cpp -mmcu=atxmega128a1u -g int.s -o int.elf

C:\SysGCC\avr\avr\include\avr>avr-objdump -S int.elf

int.elf:     file format elf32-avr


Disassembly of section .text:

00000000 <__vectors>:
   0:   0c 94 fe 00     jmp     0x1fc   ; 0x1fc <__ctors_end>
   4:   0c 94 0e 01     jmp     0x21c   ; 0x21c <__bad_interrupt>
   8:   0c 94 0e 01     jmp     0x21c   ; 0x21c <__bad_interrupt>
   c:   0c 94 0e 01     jmp     0x21c   ; 0x21c <__bad_interrupt>
  10:   0c 94 0e 01     jmp     0x21c   ; 0x21c <__bad_interrupt>
  14:   0c 94 0e 01     jmp     0x21c   ; 0x21c <__bad_interrupt>
  18:   0c 94 0e 01     jmp     0x21c   ; 0x21c <__bad_interrupt>
  1c:   0c 94 0e 01     jmp     0x21c   ; 0x21c <__bad_interrupt>
  20:   0c 94 0e 01     jmp     0x21c   ; 0x21c <__bad_interrupt>
  24:   0c 94 0e 01     jmp     0x21c   ; 0x21c <__bad_interrupt>
  28:   0c 94 0e 01     jmp     0x21c   ; 0x21c <__bad_interrupt>
  2c:   0c 94 0e 01     jmp     0x21c   ; 0x21c <__bad_interrupt>
  30:   0c 94 0e 01     jmp     0x21c   ; 0x21c <__bad_interrupt>
  34:   0c 94 0e 01     jmp     0x21c   ; 0x21c <__bad_interrupt>
  38:   0c 94 0e 01     jmp     0x21c   ; 0x21c <__bad_interrupt>
  3c:   0c 94 0e 01     jmp     0x21c   ; 0x21c <__bad_interrupt>
  40:   0c 94 0e 01     jmp     0x21c   ; 0x21c <__bad_interrupt>
  44:   0c 94 0e 01     jmp     0x21c   ; 0x21c <__bad_interrupt>
  48:   0c 94 0e 01     jmp     0x21c   ; 0x21c <__bad_interrupt>
  4c:   0c 94 0e 01     jmp     0x21c   ; 0x21c <__bad_interrupt>
  50:   0c 94 0e 01     jmp     0x21c   ; 0x21c <__bad_interrupt>
  54:   0c 94 0e 01     jmp     0x21c   ; 0x21c <__bad_interrupt>
  58:   0c 94 11 01     jmp     0x222   ; 0x222 <__vector_22>

        [!!!!!!!! VERY BIG SNIP !!!!!!!!!]

000001fc <__ctors_end>:
 1fc:   11 24           eor     r1, r1
 1fe:   1f be           out     0x3f, r1        ; 63
 200:   cf ef           ldi     r28, 0xFF       ; 255
 202:   cd bf           out     0x3d, r28       ; 61
 204:   df e3           ldi     r29, 0x3F       ; 63
 206:   de bf           out     0x3e, r29       ; 62
 208:   00 e0           ldi     r16, 0x00       ; 0
 20a:   0c bf           out     0x3c, r16       ; 60
 20c:   18 be           out     0x38, r1        ; 56
 20e:   19 be           out     0x39, r1        ; 57
 210:   1a be           out     0x3a, r1        ; 58
 212:   1b be           out     0x3b, r1        ; 59
 214:   0e 94 10 01     call    0x220   ; 0x220 <main>
 218:   0c 94 17 01     jmp     0x22e   ; 0x22e <_exit>

0000021c <__bad_interrupt>:
 21c:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>

00000220 <main>:
#define __SFR_OFFSET 0
#include <avr/io.h>

.global main
main:
        rjmp    main
 220:   ff cf           rjmp    .-2             ; 0x220 <main>

00000222 <__vector_22>:

.global TCC1_CCA_vect
TCC1_CCA_vect:
        push    r24
 222:   8f 93           push    r24
        ldi             r24, 1
 224:   81 e0           ldi     r24, 0x01       ; 1
        sts             PORTR_OUTTGL, r24
 226:   80 93 e7 07     sts     0x07E7, r24
        pop             r24
 22a:   8f 91           pop     r24
 22c:   18 95           reti

0000022e <_exit>:
 22e:   f8 94           cli

00000230 <__stop_program>:
 230:   ff cf           rjmp    .-2             ; 0x230 <__stop_program>

C:\SysGCC\avr\avr\include\avr>

As you can see that has hooked vector 22 just as one would have hoped for TCC1_CCA_vect.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jodis188 wrote:
vector 20 was generated but there is not right code for interrupt
Actually now I re-read your code maybe I misunderstood the fault you are claiming. Is this about vector 20 not vector 22? If so then you wrote:

TCC1_OVF_vect:
    push    a
    ...

and the code generated was:

000011d0 <__vector_20>:
    push a
    11d0:    2f 93           push    r18

You got exactly what you asked for didn't you ??

 

Are you talking about the other text there:

000011d0 <__vector_20>:
    sts PORTR_OUTTGL,a
    pop a
    reti*/

TCC1_OVF_vect:

That is not generated code - that is simply source annotation. The generated code will be lines like:

    11d0:    2f 93           push    r18

The lines have an address and then the bytes of the opcode. Anything else you see in the LSS is simply source annotation.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You are right Clawson

Thank you

I saw it too late...

I'am sarching since five day because during a loop, suddenly SP become 0x0000 :

i think it come from an interrupt but i can't find it. And it works when i execute step by step

regards

      Hervé

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wish you would post text not pictures!

 

Why are you limiting yourself to apparently two of the AVRs 32 registers ("a" and "b") for use in both the foreground and the and interrupt code? Surely one of the motives for switching to doing stuff in Asm not C is so you can keep some of the registers specifically for use in the ISRs and some for use in the foreground code?

 

Also why "a" and "b" anyway? Terrible names. How are those names actually any more descriptive than simply r24 or r31 or whatever thy happen to be?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I posted pictures so you can see comments in green and also where I put a breakpoint.

I used a and b for as mnemotechnic mean : many registers or bits are named in joined file.

it is to avoid using bad registers in interrupt code or asm code mixed with C code.

     Hervé

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
#define d r21
#define c r20
#define b r19			//registre utilisé "à tout va", un peu moins que a
#define a r18			//registre utilisé "à tout va"

Still not really seeing how a/b/c/d are "better" names than r21/r20/r19/r18 ?

 

Also did you just pick r21..r18 randomly or have these been specifically chosen to match the ABI of the C compiler?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

choosed after reading doc42055.pdf

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is bad form to remove your initial post.  Better to leave it all in place so others can learn from your experience.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yup, I kind of wish I'd quoted it for posterity now. The claim was (as I finally realised in #3) that the compiler was generating different code to that written in the .s but it turned out to simply be a failure in the source annotation which appeared to "lift" too much or the original source to annotate single opcode generation in the LSS

 

(#2 was a red herrring as the original code also had some commented section using TCC1_CCA_vect and at first I thought that was the claimed problem - that the compiler had generated __vector_20 rather than the hoped for __vector_22. But that was all simply my inability to read English!)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, Joeymorin...

Thankyou, Clawson

i'am even searching for the bug which clear SP register... crying

Regards

      Hervé

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also why "a" and "b" anyway?

Ex Motorola 68xx user?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Js,

No, but is shorter than AL,AH,BL,BH,... smiley and also R18, R19 !

    Hervé

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AL,AH,BL,BH

 But that's not Motorola it's 8080 family.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

8086/8088 : The ancestor of our computers