MCUCSR at reset - ATMega16

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

The first line of code in my ASM app after the JMP RESET_HANDLER at program location zero grabs MCUCSR and stores it in a SRAM variable.

I'm consistently seeing 0x47 being stored which according to the datasheet indicates the following are set:
ISC2 - which looks a bit complicated as to what it actually means!
BORF - brown out reset flag
EXTRF - external reset flag
PORF - power-on reset flag

I'm powering my circuit from the ISP pins on an STK500 and it doesn't matter whether I'm:
- turning the STK500 power on from cold
- pressing the reset switch on the STK500
- doing a forced jump to the RESET_HANDLER from within the code

I didn't expect to see 0x47 every time :cry:

Thoughts?

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

Could we see the code fragment? (Thinking of IN vs. LDS, and the address used.)

When you store to the SRAM location, nothing like a clear or preset routine is messing with it?

IIRC in a Mega16 the low 5 bits are the reset causes, and only a single one should be set.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
;******************************************************************************
.cseg
.org 0x0000 						;Interrupt handlers...
	jmp 	INTH_RESET			;Reset
	jmp 	INTH_EXT_INT0			;IRQ0
	jmp 	INTH_EXT_INT1			;IRQ1
	jmp 	INTH_TIMER2_COMP	;Timer2 Compare Match
	jmp 	INTH_TIMER2_OVF			;Timer2 Overflow
	jmp 	INTH_TIMER1_CAPT		;Timer1 Capture
	jmp 	INTH_TIMER1_COMPA		;Timer1 Compare Match A
	jmp 	INTH_TIMER1_COMPB		;Timer1 Compare Match B
	jmp 	INTH_TIMER1_OVF			;Timer1 Overflow
	jmp 	INTH_TIMER0_OVF			;Timer0 Overflow 
	jmp 	INTH_SPI_STC			;SPI Transfer Complete
	jmp 	INTH_USART_RXC			;USART RX Complete
	jmp 	INTH_USART_UDRE			;UDR0 Empty
	jmp 	INTH_USART_TXC			;USART TX Complete
	jmp 	INTH_ADC				;ADC Conversion Complete
	jmp 	INTH_EE_RDY				;EEPROM Ready
	jmp 	INTH_ANA_COMP			;Analog Comparator
	jmp 	INTH_TWI				;Two-wire Serial Interface
	jmp 	INTH_EXT_INT2			;IRQ2
	jmp 	INTH_TIMER0_COMP		;Timer0 Compare Match
	jmp 	INTH_SPM_RDY			;Store Program Memory Ready

;******************************************************************************
;include files
.include "lib_util.asm"			;utility functions
.include "lib_initialise.asm"		;initialisation code
.include "lib_comms.asm"	;comms routine
.include "lib_debug.asm"	;debug routines
;******************************************************************************

;******************************************************************************
INTH_RESET:							;main program start
;******************************************************************************

	;grab MCUCSR for later use
	in		r16, MCUCSR
	sts		MCUCSRAtReset, r16
	; etc etc

and also, elsewhere

.dseg
.org SRAM_START

MCUCSRAtReset			: .byte 0x01	;MCU status register at restart
etc etc
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It looks OK to me. You might want to have a peek at the listing to make sure that SRAM_START & MCUCSR are where you think they are. I've used the reset source on Mega16 & Mega32 and other apps with good success, but from within my C program. Let's hunt up a fragment...here is one from Mega162 (which really doesn't help directly but I'd bet CodeVision does it the same way):

         ;     781 if (MCUCSR & 1)
000071 b7e4      	IN   R30,0x34
000072 ffe0      	SBRS R30,0
000073 c003      	RJMP _0x3
         ;     782    {
         ;     783    // Power-on Reset
         ;     784    MCUCSR=0;
000074 e0e0      	LDI  R30,LOW(0)
000075 bfe4      	OUT  0x34,R30
         ;     785    // Place your code here
         ;     786 
         ;     787    }
         ;     788 else if (MCUCSR & 2) ...

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

MartinM57 wrote:
and also, elsewhere

.dseg
.org SRAM_START

MCUCSRAtReset			: .byte 0x01	;MCU status register at restart
etc etc

I'm no think so, best place for ".org SRAM_START" is on the begining. If .dseg directive was anywhere before and you declare inside there any .byte, I think you ask troubles... ;) To check this you need "Generate lst file" checked in Assembler options, and view *.lst file.
Try this at begining of code :
.dseg
.org SRAM_START
MCUCSRAtReset:
.byte 0x01	;MCU status register at restart
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmmm...I can't see the difference between your code and mine :(

I have about 60 other variables in .dseg plus a couple of buffers that all work fine, so I'm pretty confident that my .dseg declarations are OK. MCUCSRAtReset isn't the first one declared so it doesn't look like it's an 'edge' effect

But there is something strange going on in my app - I was querying the value of MCUCSRAtReset via the UART using Bray's Terminal. If I send MCUCSRAtReset out of the UART as soon as possible in my app (ie after the UART setup) I'm now seeing 0x03 - Power-on Reset AND External Reset

Is that more like what is expected - I thought I might just see 0x01 - Power-on Reset?

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

Hmmm..mega embarassment here :oops:

I was seeing 0x2F rather than the 0x47 in the original post and I had a coding bug between the order of variables send by the processor and the order received in the PC anyway.

So the real value I'm now seeing is a reliable 0x03 - external reset and power-on reset, which, I guess, is sort of understandable ....

..sorry to trouble the assembled 'Freaks' brains. Martin

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

Just to clean this up for anyone searching....

The code should be

	
	;grab MCUCSR for use in initialisation and then reset it
	in		r16, MCUSR
	sts		MCUCSRAtReset, r16
	ldi		r16, (0<<WDRF)|(0<<BORF)|(0<<EXTRF)|(0<<PORF)
	out		MCUSR, r16

MCUSR seems to contain the cumulative set of resets since power-up - so if you don't reset MCUSR after reading it, you see what I saw, namely 0x03 (external reset and power-on reset), after an external reset

If you reset MCUSR after grabbing it, then next time you only see the single reason for the (last) reset

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

> ldi r16, (0<<WDRF)|(0<<BORF)|(0<<EXTRF)|(0<<PORF)

This appears to be a brain-twisting overly complicated form of
writing

ldi r16, 0

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

...it's called "self-documenting code" ;)

...and I missed out JTRF, as well ...