Unexpected result when using ISR_NAKED

Go To Last Post

13 posts / 0 new

Author

Message

dpaulsen

Level: Hangaround

Joined: Thu. Apr 27, 2006

Posts: 257 View posts

Location: San Jose, CA

Posted by dpaulsen: Wed. Aug 25, 2010 - 11:29 PM

Here is my code:

#define RX_MODE PORTD &= ~(1<<PD4);

...

ISR(USART1_TX_vect, ISR_NAKED){
	RX_MODE
	reti();
}

After compiling it looks like this:

 584               	.global	__vector_30
 586 031e 8F5F      	__vector_30:
 588 0324 00C0      	.LM64:
 589               	.LFBB5:
 590               	/* prologue: naked */
 591               	/* frame size = 0 */
 593               	.LM65:
 594               		cbi 43-32,4
 194:SMain.c       **** 
 195:SMain.c       **** ISR(USART1_TX_vect, ISR_NAKED){
 595               	pilogue start */
 597               	.LM67:
 598               	/* #NOAPP */
 196:SMain.c       **** 	RX_MODE
 600               	pe5:
 602 0326 5C98      	.global	main
 197:SMain.c       **** 	reti();
 603               	ype	main, @function
 604               	main:
...

I have two questions.

1) Why is there no reti?
2) What in the world is ype?

Tags:

Tools, Compilers and General Programming

Koshchi

Level: 10k+ Postman

Joined: Wed. Nov 17, 2004

Posts: 15674 View posts

Location: Vancouver, BC

Posted by Koshchi: Thu. Aug 26, 2010 - 02:22 AM

My question to you: what version of avr-gcc are you using?

Also, look down farther and see if you can find 1895 somewhere.

Regards,
Steve A.

The Board helps those that help themselves.

clawson

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 97867 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

Posted by clawson: Thu. Aug 26, 2010 - 08:30 AM

The source annotation in that does not match the opcodes listed. Look at the second line for example that start 586. It has "031e 8f5f" showing that two words have been generated. Now look at the source annotation - it is "__vector_30:". Why would a LABEL have generated ANY words whatsoever?

How was this file produced. It looks like a .s but they don't have the addresses/generated bytes. But then again it's not a .lss either as it's showing avr-as directives whereas the .lss is a disassembly (with source annotation) of the object.

EDIT: I'm not sure of the endianism but if I type either "031E 8F5F" or "1E03 5F8F" into the first two locations of program memory in the AVR Simulator I get either:

+00000000:   031E        FMUL      R17,R22        Fractional multiply unsigned
+00000001:   8F5F        STD       Y+31,R21       Store indirect with displacement

+00000000:   1E03        ADC       R0,R19         Add with carry
+00000001:   5F8F        SUBI      R24,0xFF       Subtract immediate

The latter seems more likely than the former. But for sure this isn't what the source annotation says.

Last Edited: Thu. Aug 26, 2010 - 08:39 AM

JohanEkdahl

Level: 10k+ Postman

Joined: Wed. Mar 27, 2002

Posts: 26988 View posts

Location: Lund, Sweden

Posted by JohanEkdahl: Thu. Aug 26, 2010 - 08:39 AM

Just a note of style, not pertaining to your current problem:
Instead of placing a semicolon in the macro definition,, I recommend placing it at the macro "call", ie

#define RX_MODE PORTD &= ~(1<<PD4)

...

ISR(USART1_TX_vect, ISR_NAKED){
   RX_MODE;
   reti();
}

i) Your technique has a bigger probability of coming back and biting you when you least expect it, and "macro bugs" are confusing, strange and hard to spot.
ii) It is the more commonly used style, so other looking at you code will not get as confused as when seeing the macro call w/o a semicolon.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Koshchi

Level: 10k+ Postman

Joined: Wed. Nov 17, 2004

Posts: 15674 View posts

Location: Vancouver, BC

Posted by Koshchi: Thu. Aug 26, 2010 - 03:29 PM

Quote:

I'm not sure of the endianism

The listing has the least significant byte first, so the 00C0 is an RJMP 0, and the 5C98 is the CBI PORTD, 4.

The reason I asked about the version of avr-gcc is that in a prior thread they had an lst file that was jumbled like this. They were using gcc 4.5.

Edit: This was the thread.

Regards,
Steve A.

The Board helps those that help themselves.

dpaulsen

Level: Hangaround

Joined: Thu. Apr 27, 2006

Posts: 257 View posts

Location: San Jose, CA

Posted by dpaulsen: Thu. Aug 26, 2010 - 03:31 PM

Im using WINAVR 20100110 which came with avr-gcc 4.3.3.

Give me a sec and I will post the whole lst file

wek

Level: Raving Lunatic

Joined: Fri. Dec 16, 2005

Posts: 3271 View posts

Location: Bratislava, Slovakia

Posted by wek: Thu. Aug 26, 2010 - 03:43 PM

dpaulsen wrote:

Give me a sec and I will post the whole lst file

Here you are:

sec

:-P

---

Isn't it some postprocessed stuff, e.g. copied/pasted from some "smart" IDE?

dpaulsen

Level: Hangaround

Joined: Thu. Apr 27, 2006

Posts: 257 View posts

Location: San Jose, CA

Posted by dpaulsen: Thu. Aug 26, 2010 - 03:45 PM

I attached the files.

Note that I have worked on other parts of the code so its not exactly the some as my original post. However the issue is still there.

It correctly shows the reti in the .lss file.

I originally posted because I thought that is might me my limited understanding of assembly language. Now that I know that it is a glitch I am not too worried about it.

Attachment(s):

SMain_Forum.lst.txt

SMain_Forum.lss.txt

clawson

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 97867 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

Posted by clawson: Thu. Aug 26, 2010 - 04:01 PM

But tell us how this listing was generated. It does not appear to be by any standard means. Look at just a small part of the .lst:

 360 01a4 2093 0000 	.Lscope2:
 362 01aa 00C0      	.global	__vector_18

Once again it is putting labels and directives against address/code bytes - this simply does not make sense.

If I build the very smallest of test programs for a mega128:

#include  
#include 

int main (void) 
{ 
	while(1){ 
	} 
} 

#define RX_MODE PORTD &= ~(1<<PD4) 

ISR(USART1_TX_vect, ISR_NAKED){ 
   RX_MODE; 
   reti(); 
}

then the .lss shows:

int main (void) 
{ 
  be:	ff cf       	rjmp	.-2      	; 0xbe 

000000c0 <__vector_32>:
} 

#define RX_MODE PORTD &= ~(1<<PD4) 

ISR(USART1_TX_vect, ISR_NAKED){ 
   RX_MODE; 
  c0:	94 98       	cbi	0x12, 4	; 18
   reti(); 
  c2:	18 95       	reti

and the .lst shows:

  48               	.global	main
  50               	main:
  51               	.LFB2:
  52               	.LM1:
  53               	/* prologue: function */
  54               	/* frame size = 0 */
  55               	.L2:
  56 0000 00C0      		rjmp .L2	 ; 
  57               	.LFE2:
  59               	.global	__vector_32
  61               	__vector_32:
  62               	.LFB3:
  63               	.LM2:
  64               	/* prologue: naked */
  65               	/* frame size = 0 */
  66               	.LM3:
  67 0002 9498      		cbi 50-32,4	 ; ,,
  68               	.LM4:
  69               	/* #APP */
  70               	 ;  14 "test.c" 1
  71 0004 1895      		reti
  72               	 ;  0 "" 2
  73               	/* epilogue start */
  74               	.LM5:
  75               	/* #NOAPP */
  76               	.LFE3:
 110               	.Letext0:

and the .s shows:

.global	main
	.type	main, @function
main:
.LFB2:
.LM1:
/* prologue: function */
/* frame size = 0 */
.L2:
	rjmp .L2	 ; 
.LFE2:
	.size	main, .-main
.global	__vector_32
	.type	__vector_32, @function
__vector_32:
.LFB3:
.LM2:
/* prologue: naked */
/* frame size = 0 */
.LM3:
	cbi 50-32,4	 ; ,,
.LM4:
/* #APP */
 ;  14 "test.c" 1
	reti
 ;  0 "" 2
/* epilogue start */
.LM5:
/* #NOAPP */
.LFE3:
	.size	__vector_32, .-__vector_32

EDIT: looking further at your .lst it starts to get out of step here:

 281               	.global	__vector_15
 283               	__vector_15:
 116:SMain.c       **** 
 117:SMain.c       **** ISR(TIMER1_OVF_vect){
 284               	 r0,__SREG__
 285               		push r0
 286               		clr __zero_reg__
 287 0126 1F92      		push r18
 288 0128 0F92      		push r19
 289 012a 0FB6      		push r20
 290 012c 0F92      		push r21
 291 012e 1124      		push r24
 292 0130 2F93      		push r25
 293 0132 3F93      	/* prologue: Signal */
 294 0134 4F93      	/* frame size = 0 */

Not sure what was going on with "284" and where's the code that the opcodes at "285"/"286" generated? I'm guessing it's whatever went wrong at "284" that is the root of the problem.

EDIT2: personally I've never known the .lss to be wrong and it isn't in this case either - it correctly shows:

ISR(USART1_TX_vect, ISR_NAKED){
	RX_MODE
 2dc:	5c 98       	cbi	0x0b, 4	; 11
	reti();
 2de:	18 95       	reti

Moral - forget the .lst it appears to be utter crap!

dpaulsen

Level: Hangaround

Joined: Thu. Apr 27, 2006

Posts: 257 View posts

Location: San Jose, CA

#10

Posted by dpaulsen: Thu. Aug 26, 2010 - 04:24 PM

Quote:

But tell us how this listing was generated.

Not sure what you mean by this. It was generated by avr-gcc 4.3.3.

Anyhow I am not too concerned at this point. If it really starts to bother me I will try updating my avr-gcc. I am not sure exactly how to do this since my original copy was intalled with WINAVR.

Koshchi

Level: 10k+ Postman

Joined: Wed. Nov 17, 2004

Posts: 15674 View posts

Location: Vancouver, BC

#11

Posted by Koshchi: Thu. Aug 26, 2010 - 04:31 PM

Quote:

If it really starts to bother me I will try updating my avr-gcc.

But it looks like just the .lst is wrong. The .lss looks just fine, so I see no need to worry.

Regards,
Steve A.

The Board helps those that help themselves.

clawson

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 97867 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#12

Posted by clawson: Thu. Aug 26, 2010 - 04:36 PM

Quote:

Not sure what you mean by this. It was generated by avr-gcc 4.3.3.

Ah well it seems to be this that does it:

CFLAGS += -Wa,-adhlns=$(<:%.c=$(OBJDIR)/%.lst)

where avr-gcc is being told to pass that command through to the assembler so it'd be worth looking at the buglist for binutils to see if this has been raised already.

dpaulsen

Level: Hangaround

Joined: Thu. Apr 27, 2006

Posts: 257 View posts

Location: San Jose, CA

#13

Posted by dpaulsen: Thu. Aug 26, 2010 - 04:40 PM

Koshchi wrote:

Quote:
If it really starts to bother me I will try updating my avr-gcc.
But it looks like just the .lst is wrong. The .lss looks just fine, so I see no need to worry.

Yes, indeed it is not bothering me at this point.

Thanks everyone. I appreciate your guidence.

Jump To

Search form