Undeterminable RESET Issue. [SOLVED]

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

I'm playing with assembly using the ATMega328 controller in the PDIP package.

The project board is the Arduino Duemilanove running at 18.432 MHz. I changed the crystal from 16.000 MHz to obtain the "Magic " frequencies for good USART operation.

Serial communications is via FTDI USB connection

AVR Studio                 4.18.700  
GUI Version                4, 18, 0, 685
Build                      2600
Service Pack               3

Plugins:
AvrPluginAvrAsmObject      1, 0, 0, 48
AvrPluginavrgccplugin      1, 0, 0, 11
Stk500Dll                  1, 0, 1, 15

I'm also using an ATAVRISP MKII USB ISP programmer connected to a standard on-board ISP headder.

In addition, I'm using HyperTerminal as a used display for observation of experiments. The Communications speed is 115.2K BAUD.

Basically, I'm putting text

The issue is this...

When I assemble, the results are error free. When I download the code runs just fine.

Now the problem is that, as long as I don't remove power, the code runs as expected. But if I power down the project board, some aspects of the code won't run correctly.

Another issue that I have observed is that when I start HyperTerminal, it sends some character to the project board. When the project board receives the character (more like packet, I guess) the project board goes into RESET and from then on, data is trashed. The USART code DOES NOT use any interrupts so I can't get a grasp of why the controller is entering reset.

The fact that the controllers is resetting has been proven by two methods.

The first indication that the controller is being RESET is that when I close out a HyperTerminal session and then restart another session (without leaving HyperTerminal) the terminal screen clears and the text gets reinitialized.

The indication is that I've put the status of the MCUSR register in the terminal screen and every time I reinitialize a communications session, the MCUSR comes up with 0x02, which is the external RESET flag.

So the issues are:

RESET caused by reception of spurious USART character.

Code characteristics change after repowering the controller.

It seems to me that I have heard about a scenario like this several years ago, but a forum search doesn't seem to reveal anything with symptoms like this.

Does anyone have any clues or, has anyone heard of such a thing?

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

Last Edited: Wed. Oct 20, 2010 - 08:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An Arduino user will know more about this but I thought there was some mechanism within the FTDI that allowed it to be used to invoke a _RESET in the CPU for purposes of triggering bootloading?

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

clawson wrote:
An Arduino user will know more about this but I thought there was some mechanism within the FTDI that allowed it to be used to invoke a _RESET in the CPU for purposes of triggering bootloading?

You know what, Cliff? I hadn't even thought about that.

But that still doesn't take into acocunt, the change in code characteristics when the device has it's power cycled.

All in all, the Arduino Duemilano is pretty much a generic or minimal design, not much different then some of the simply controller boards I've designed.

The only thing I can see that might be different in the design is the fact that the Arduino board doesn't hace a capacitor connected to the RESET line. But I don't think that would cause the code performance change issue random RESETS, maybe, but not altered performance.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

Ok!

Looking at the schematic, DTR and RTS are connected to the controllers RESET line. I guess an Oscilloscope session will prove the concept that DTR or RTS is putting the controller into a hard RESET.

As for the code performance changes, I'll look around the code some more and see if I'm missing some variables are not being initialized, that should be.

I guess that leads to another question... I know that when the AVR is first powered up, all of registers and I/O space are placed in a known state, but is RAM space also zero'd out? I haven't ever seen anything mentioned about this, to my recollection.

Thanks, Cliff.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

microcarl wrote:
I know that when the AVR is first powered up, all of registers and I/O space are placed in a known state, but is RAM space also zero'd out? I haven't ever seen anything mentioned about this, to my recollection.
If you are using WinAVR (GCC), the avr-libc .init(something) code zeroes out RAM in the .data and .bss sections on start-up. If there is RAM that you want to be left alone after a reset, put it in the section .noinit.

Stu

Edit 1: Actually, the .bss section is reset; the .data section is set to the initialization values you supply.

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

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

Quote:
If you are using WinAVR (GCC)....I'm playing with assembly
From other posts I know it's the Atmel ASM :wink:
Quote:
but is RAM space also zero'd out?
Only if you do it at start up (part of init.asm)
;Clear all memory
clr_mem:
	ldi		yh,high(SRAM_START)	
	ldi		yl,low(SRAM_START)
	clr		temp
	ldi		temp1,high(ramend-1)	;Leave last 2 addresses,return address
clr_mem_lp:
	st		y+,temp
	cpi		yl,low(ramend-1)	
	cpc		yh,temp1
	brne	clr_mem_lp

my init is a subroutine therefore the last 2 bytes are preserved.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Carl,

i do not know about the board itself, and how the power supply is organized.
But you might get unexpected behaviour if you extir reset state while the power supply is not yet stable. Perhaps this is part of the problem. You could put a little 10nF or 100nF cap on reset and see what happens. Is do not know if changing the fuses to wait longer after reset release will also perhaps help.
What I sometimes have here is that when I power cycle a board that the FTDI chip is lost or the communication to the PC ( I use hyperterminal most of the times) is broke. When I disconnect and reconnect the hyperterminal all starts working again. Or another power cycle sometimes also does the trick.

perhaps you could try that.

regards

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

Carl could you be triggering the arduino bootloader (hyperterm strange chars) , or is the chip "blank" ... meaning ISP reprogrammed (by you) ?

If you still have the bootloading , the Bootloader prob expects 16Mhz for the bootloader speed , and could (might) do strange things with the flash.

/Bingo

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

Well, I solved the problem. After you spend so long (about two days) everything starts looking the same, if not a bit blury.

The problem was simple, really.

The offending instruction was:

lds		accb, 16    ; Load 16, something-or-other

and it should have been:

ldi		accb, 16    ; Load imediated value

Thanks for the help...

Oh...

Here is the full routine where the bug was located.

;Sunday, October 17, 2010

/*------------------------------------------------------------------------------*/ 
;************ --- ROUTINE TO CONVERT BINARY FORMAT TO BCD FORMAT --- ************/
/*------------------------------------------------------------------------------*/ 

; This routine ("BinToBcd") converts a 16 bit "Binary" number held in a two byte
; variable called "Integer" into a five digit packed "BCD" number.

; The results of the "Binary" to "BCD" conversion is placed into a three byte
; variable called "Result".

; A routine called "BcdToAscii" is then executed where the five digit "BCD" number
; is converted to an "ASCII" string, located in a ten byte RamSpace buffer called
; "AsciiBuff".

; Finally, a routine called "ZeroSupp" is called where the decimal point position
; is set, leading zeros are suppressed and the ASCII string "AsciiBuff" is
; transmitted to the user consol using "USART0_PutString".

; Function name:							->	BinToBcd

; Convert two byte binary integer to 5 ASCII digits and send to terminal

; Registers used:
;						Temp			->	r23
;						acca			->	r24
;						accb 			->	r25
;						XL			->	r26
;						XH			->	r27
;						YL			->	r28
;						YH			->	r29
;						ZL			->	r30
;						ZH			->	r31

; Ram space used:
;				000106	Integer:		.byte 2	->	Integer binary input
;				000108	Result:		.byte 3	->	Packed BCD Result
;				00010b	BCD_Data:	.byte 3	->	Packed BCD output	

; On entry:
;				accb holds the desired decimal point position
;				Integer:Integer+1 -> hold the binary data to be converted to BCD

; On exit:			MS  Byte			 LS  Byte
;				BCD_Data:BCD_Data+1:BCD_Data+2 -> hold the packed BCD data

; Routines called:
;                  			BcdToAscii


BinToBcd:
			push		accb			; Save the cursor position

			ldi		YL, low(Result)	; Get the starting address of Result
			ldi		YH, high(Result)

			ldi		acca, 0x00		;Clear the Result
			std		Y+0, acca
			std		Y+1, acca
			std		Y+2, acca

			ldi		accb, 16
ShftLoop:
			push		accb			; Preserve the bit shift counter
			ldi		YL, low(Result+2)	; Get the last address of Result
			ldi		YH, high(Result+2)
			ldi		accb, 3			; There are 3 Result bytes to be processed
			ldd		acca, Y+0		; Get current byte to be converted
BcdLoop:
			push		accb			; Preserve the byte counter
			mov		accb, acca		; Transfer acca to accb -> Preserve acca
			andi		acca, 0x0F		; Clear the high nibble
			subi		acca, 0x05		; Check for improper BCD digit
			brmi		AT			; Is this a good BCD digit ?
			
			ldi		Temp, 0x03			
			add		accb, Temp
AT:
			mov		acca, accb		; Transfer accb to acca -> recover acca
			andi		acca, 0xF0		; Clear the low nibble
			subi		acca, 0x50		; Check for improper BCD digit
			brmi		BT			; Is this a good BCD digit

			ldi		Temp, 0x30
			add		accb, Temp		; No! Correct the displaced bits
BT:
			std		Y+0, accb		; Store the data at the current address

			pop		accb			; Recall the byte counter
			dec		accb			; Have we 3 bytes?
			brne		NoResult
			rjmp		ResultDone
NoResult:
			ld		acca, -Y		; Get next byte and decrement address pointer			
			rjmp		BcdLoop
ResultDone:
			ldi		ZL, low(Integer)	; Get the starting address of Integer
			ldi		ZH, high(Integer)
			ldi		YL, low(Result)	; Get the starting address of Result
			ldi		YH, high(Result)

			ldd		acca, Z+1
			lsl		acca			; Shift to set up for the next conversion
			std		Z+1, acca
			ldd		acca, Z+0
			rol		acca
			std		Z+0, acca
			ldd		acca, Y+2
			rol		acca
			std		Y+2, acca
			ldd		acca, Y+1
			rol		acca
			std		Y+1, acca
			ldd		acca, Y+0
			rol		acca
			std		Y+0, acca

			pop		accb			; Recall the bit shift counter
			dec		accb
			brne		ShftLoop		; Have we looped 16 bit shifts ?

			lds		acca, Result
			sts		BCD_Data, acca
			lds		acca, Result+1
			sts		BCD_Data+1, acca
			lds		acca, Result+2
			sts		BCD_Data+2, acca

			pop		accb			; Recover the decimal point position
	 		rcall		BcdToAscii

			ret

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

Last Edited: Wed. Oct 20, 2010 - 06:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Carl,

if all starts looking blurry, then most of the times I need to claen my glasses ;)

glad to see that the bug was that simple to solve.