Interesting Mega128 and assembly Language Puzzler

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

I wrote the below simple test program for an Atmega128 MCU running at 14.xx mhz and set the fuse as a 128 not a 103.
When you run the program on a real Mega128 it works just fine.
But I noticed that PortG pins 0,1,2,3 toggle in sequence with portB too.
I don't understand why PortG is doing that. I thought it was still defaulted to inputs as well.
Does someone know?
Thanks
Earl

;mega128 LED test program
; By Earl Bollinger
.include "m128def.inc" ;Includes the m128 definitions file

;define the variables being used
.def Temp = R16
.def delay1 = R17
.def delay2 = R18
.def delay3 = R19

.org 0x0000 ;Start the program code at address 0x0000
rjmp RESET ;Take a Relative Jump to the RESET Label

RESET:
; initialize the stack pointer
ldi Temp,HIGH(RAMEND)
out SPH,Temp
ldi Temp,LOW(RAMEND)

ldi Temp, 0xFF ;Store 255 in Temp
out DDRB, Temp ;Save in The PORTB DDR (make PORTB all outputs)

Loop:
out PORTB, Temp ;Write Temp to PORTB
dec Temp ;Decrement Temp
rcall Timedelay ; slow it down
;rcall Timedelay
rjmp Loop ; Loop Endlessly

; Time Delay SubRoutine
; The three registers or variables are nested
; to perform 255 loops within 255 loops within 16 loops
Timedelay:
ldi delay1,0xFF
Aloop:
ldi delay2,0xFF
Bloop:
ldi delay3,0x10
Cloop:
dec delay3
brne Cloop
dec delay2
brne Bloop
dec delay1
brne Aloop
ret

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

If you turn on external memory (by accident or on purpose?) the port g pins become /rd and /wr and would start wiggling like crazy...... is this the problem?

Imagecraft compiler user

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

Hi,

Not that it could cause your problem and perhaps it is a typo but there is no "out SPL,temp" code.

Regards,
Steve

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

I think that might be it on both accounts.
Thanks guys, I appreciate it.

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

/rw and /wr should not wiggle unless you write/read!

Regards

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

I guess it has me stumped.
I didn't see anything obvious in the fuse bits for enabling or disabling external memory.
I added the out spl,temp line as it was a error.
The Portg0,g1,g2 pins all toggle in unison with the respective pins of PortB0,1,and 2.
A earlier even simpler program, uses only R16 and R17 registers, the PortG pins don't toggle with it.
Is it my use of Registers 18 and 19 actually causing the problem?

;A simple program
.include "m128def.inc" ;Includes the m128 definitions file

;define the variables being used
.def Temp = R16
.def delay1 = R17
.def delay2 = R18
.def delay3 = R19

.org 0x0000 ;Start the program code at address 0x0000
rjmp RESET ;Take a Relative Jump to the RESET Label

RESET:
; initialize the stack pointer
ldi Temp,HIGH(RAMEND)
out SPH,Temp
ldi Temp,LOW(RAMEND)
out SPL,Temp

ldi Temp, 0xFF ;Store 255 in Temp
out DDRB, Temp ;Save in The PORTB DDR (make PORTB all outputs)

Loop:
out PORTB, Temp ;Write Temp to PORTB
dec Temp ;Decrement Temp
rcall Timedelay ; waste some time
;rcall Timedelay
rjmp Loop ; Loop Endlessly

; Time Delay SubRoutine
; The three registers or variables are nested
; to perform 255 loops within 255 loops within 16 loops
Timedelay:
ldi delay1,0xFF
Aloop:
ldi delay2,0xFF
Bloop:
ldi delay3,0x10
Cloop:
dec delay3
brne Cloop
dec delay2
brne Bloop
dec delay1
brne Aloop
ret

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

Hi,

I tried your code on my STK500/501. I tried it with the software generated clock at 3.69MHz and with the onboard crystal generated clock using a 15MHz crystal. I did not see the PortG pins toggling. At 3.69MHz PG0 and PG1 were high and all remaining PG pins were low. At 15MHz PG0 was low, PG1 was high and remaining PG pins were low. The LED's connected to portB appeared to change their count rate by ~4 which jives with the clock change. My fuses were set as follows, no JTAG, clock set to external oscillator (for both 3.69MHz and 15MHz), brown out set for 4.0V. I have not looked at the datasheet or the STK501 schematics yet to see if I can figure out why PG0 and PG1 acted as they did. My first gut feeling is that all PG pins should be low.

Interesting :!:

Regards,
Steve

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

I have a BASCOM program that toggles LED's on Port B and G individually just fine. Thus it doesn't appear to be any shorted I/O lines.
So there must be something in my assembly program I am doing wrong.
I mess with it some more tonight.
Thanks for looking.
I think I'll have to break out my STK500/501 and give it a whirl on it too.
Thanks