Inconsistent runtime behaviour

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

The code at the end runs fine (it doesn't really matter what it does, but some forum members might spot some of the style :) )

(Don't know why the layout is awful - it's OK in Studio)

Can I ask some/all to:
- load it into Studio and run it in the simulator. Put a breakpoint at the line after DONE: and run it, Note that everytime you do, r18 = 0x78 and r19 = 0x35, just as required. Single step the code and watch the PORTB output - just what you'd expect

- Now download it to an 8515 (or an m16, if you change the .include - it should work OK) in an STK500. Watch the LEDs. Do they indicate what they should (0x78)? Press the Reset button on the STK500. Watch the LEDs - are they the same? Press the Reset button on the STK500. Watch the LEDs - are they the same? Press the Reset button on the STK500. Watch the LEDs - are they the same?

On mine I get a different set of LEDs illuminated each time. But the processor is being reset each time, so what is causing the different results?

.include "m8515def.inc"

.DEF ZERO = R15					;USED AS IMMEDIATE ZER0
.DEF X1   = R16					;X1
.DEF X2   = R17					;X2 AND DELTA-X
.DEF Y1   = R18					;<== FINAL ANSWER HERE
.DEF Y1H  = R19
.DEF Y2   = R20					;Y2 AND DELTA-Y
.DEF Y2H  = R21
.DEF Y2HH = R22
.DEF IX   = R23					;GIVEN X AND X-OFFSET
.DEF TMP  = R24					;WORKSPACE
.DEF TMPH = R25
.DEF N    = R26					;LOOP COUNTER
 
.SET X1_VALUE = 24
.SET X2_VALUE = 50
.SET Y1_VALUE = 9454 
.SET Y2_VALUE = 14241
.SET X_VALUE  = 47

	;PORTB initialisation - visual debug
	ser		r16
	out		ddrb, r16
	
	ldi		X1 ,X1_VALUE		;LOAD TEST DATA
	ldi		X2 ,X2_VALUE
	ldi		Y1 ,LOW(Y1_VALUE)
	ldi		Y1H,HIGH(Y1_VALUE)
	ldi		Y2 ,LOW(Y2_VALUE)
	ldi		Y2H,HIGH(Y2_VALUE)
	ldi		IX ,X_VALUE 

	clt							;NEG-SLOPE FLAG
	clr		ZERO				;USED AS A ZERO
	sub		Y2,Y1				;CALC dY INTO Y2
	sbc		Y2H,Y1H
	breq	DONE				;IF Y1=Y2? WE'RE DONE!
	brcc	NOTNEG				;GO IF SLOPE POSITIVE
	set							;NEGATIVE SLOPE..
	neg		Y2					;CONVERT TO POSITIVE
	adc		Y2H,ZERO  
	neg		Y2H        
NOTNEG:
	sub		X2,X1				;CALC dX INTO X2
	breq	DONE				;IF X1=X2? WE'RE DONE!
	sub		IX,X1				;CALC (X-X1) INTO IX
	breq	DONE				;IF X=X1? WE'RE DONE!
	cp		IX,X2				;DOES X=X2?
	breq	Y2OUT				;YES? THEN ANS IS Y2!
INTERP:
	movw	TMP,Y2				;MULTIPLY dY(X-X1)
	mul		TMP,IX 
	movw	Y2,R0
	mul		TMPH,IX
	add		Y2H,R0
	adc		Y2HH,R1
	adc		Y2HH,ZERO
	ldi		N,16				;CALC dY(X-X1)/dX
LUPIE:
	rol		Y2
	rol		Y2H
	rol		Y2HH
	cp		Y2HH,X2
	brcs	SKPSUB
DOSUB:
	sub		Y2HH,X2
	clc
SKPSUB:
	dec 	N
	brne	LUPIE
	rol		Y2       
	rol		Y2H
DVDONE:
	com		Y2
	com		Y2H
	brts	SLPNEG				;NEG-SLOPE?
	add		Y1,Y2				;ANS=Y1+dY(IX-X1)/dX
	adc		Y1H,Y2H
	rjmp	DONE    
SLPNEG:
	sub		Y1,Y2				;ANS=Y1-dY(IX-X1)/dX
	sbc		Y1H,Y2H
	rjmp	DONE
Y2OUT:
	movw	Y1,Y2				;ANS=Y2
DONE:

	mov		r16, Y1H
	com		r16
	out		portb, r16
	mov		r16, Y1
	com		r16
	out		portb, r16

loop:
	rjmp	loop

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

...edit of title and commentary - described the problem more obviously

Any ideas greatfully received - it's doing my head in!

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

I don't see anything that assigns Y2HH before it's first used.

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

Well spotted!

Making an assignment to y2hh at the start stops the random result on the LEDs

So if that is the problem, does that mean that registers have undefined (and different, but depending on what?) values at reset in the AVR

Thanks!

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

Quote:
does that mean that registers have undefined (and different, but depending on what?) values at reset in the AVR

Yes. Contents of SRAM and regs depends mostly on their values at the microsecond when the reset signal was asserted.

Andreas

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

I don't think TMPH is initialzied either before use. CLR it.