Random Resets of 14m2 when using DO ... LOOP [FIXED - Power supply issue]

Anobium

Senior Member
I was getting random resets of the code below when I used a DO ... LOOP rather than the main: .... goto main instruction the random resets have stopped.


I have a relative simple circuit in the AXE091 board with an external switch - the purpose of the application is to count the switch on/off cycle. The switch has a 10k pull down and I also have fitted a cap to the switch contacts. I have then tied the switch to c.3 via a 1k.
Also have a LED and an additional push switch of the AXE091 board. A piezo sounder on b.2
I have connected the SEROUT on c.0 to my PC via 180r (there is no serin connected)​


The switch activites every 30-60 seconds, the switch may stay closed during a cycle hence the loop exits for the display.

Any thoughts? Have I messed up the PULLUP command?

Thank you,

Anobium



Code:
#Picaxe 14m2
#Terminal 38400
' reset EEPROM
EEPROM 2,(0,0)

' reset to current count value. load the two bytes into the EEPROM
EEPROM 0,(144,0)


' OutPorts
symbol ledport = b.1
symbol soundport = b.2
symbol commsport = c.0

' InPorts
symbol switchmonitorport = pinc.3				 'Has 10k pull down resistor fitted
symbol showcurrentvaluesswitchpushed = pinc.4		 'Has 10k pull down resistor fitted AXE 091 SW3

' constants
symbol mem_lobyte = 0
symbol mem_hibyte = 1
symbol mem_switchstate = 2
symbol mem_resetcount = 3

symbol blink = 20

' memory mapping
symbol currentcount = w0
symbol lbyte_currentcount = b0
symbol hbyte_currentcount = b1
symbol countdots = b2
symbol currentstate = b3
symbol restartcount = w3

' initialise
{
' bits  7654321076543210 
pullup %0000011100111110
' conn  ---XX------XX---

low ledport
countdots = 0
setfreq m32
}

' Read current reset count from EEPROM
{read mem_resetcount, restartcount
inc restartcount
write mem_resetcount, restartcount
serout commsport,n4800, ("On @ ", #restartcount, 13, 10 )
gosub show2
gosub pout1:gosub pout1
}

' Main loop
main:{
	setfreq m32
	' call Sub as this Sub routine is reused below
	gosub show1
		
	read mem_switchstate, currentstate	
	if switchmonitorport = 1 then
		high ledport
		if currentstate = 0 then
			write mem_switchstate, 1	
			serout commsport,n4800, (27,"[1GIncrement Count ")
			read mem_lobyte, lbyte_currentcount
			read mem_hibyte, hbyte_currentcount
			
			inc currentcount
			write mem_lobyte, lbyte_currentcount
			write mem_hibyte, hbyte_currentcount
			
			gosub pout
			do while switchmonitorport = 1
				pause blink
				gosub show1
			loop	
		end if			
	end if
	if switchmonitorport is off then
		write mem_switchstate, 0
		low ledport
	end if
}
goto main

' Output current reading value
{
pout:
	' current value
	serout commsport,n4800, (#currentcount, " @ ", #restartcount)

pout1:
	' output sound
	serout commsport,n4800, (13,10)
	setfreq m4
	Sound soundport,(50,10,0,10,125,10,0,10)
	setfreq m32
	return
}
	
' Output text to the current line
{
dotout:

		if countdots = 127 then 
			serout commsport,n4800, (27,"[1G.")
		end if
		if countdots = 255 then 
			serout commsport,n4800, (27,"[1G")
		end if

return
}

' Tidy up the current display line
{
tidyout:
		if countdots > 127 then 
			serout commsport,n4800, (27,"[1G")
		end if

return
}

' Handle current reading
{
show1:
	if showcurrentvaluesswitchpushed = 1 then
		gosub show2
		do while showcurrentvaluesswitchpushed = 1
			gosub dotout
			pause blink
			inc countdots
		loop
	else
		gosub dotout			
		inc countdots
	end if

return
}

' Show current reading
{
show2: 
	serout commsport,n4800, (27,"[1GCurrent Count " )
	read mem_lobyte, lbyte_currentcount
	read mem_hibyte, hbyte_currentcount
	gosub pout
return
}
 

Attachments

Anobium

Senior Member
I will remove the LED and the Sounder and test for stability.

I have changed the code to main: .... Goto main, and it just rebooted. I will remove the Led and sounder next.

Thank you.
 

hippy

Senior Member
I have changed the code to main: .... Goto main, and it just rebooted.
DO ... LOOP is compiled exactly as if it were <label>: ... GOTO <Label> so no difference should be observed. Whatever is causing a program crash would almost certainly be elsewhere.
 

Anobium

Senior Member
@MPep - I am not ignoring you reply. I am adapting. I have the device on test now with the two devices removed. If this fails I am not sure what to do next. I will revert when the results soon.

@hippy - OK - that rules out any compiler and f/w issue. Thank you. I will start looking elsewhere - I am starting by removing devices.
Is the PULLUP ok?​
 
Last edited:

Anobium

Senior Member
Question: What is the impact of using n4800 rather then N4800_32? I ported the code from an 08m last week and used an m2 device. Would the use of n4800 have a material impact?
 

hippy

Senior Member
Using N4800 at 32MHz won't use 4800 baud so, yes, that would have an affect but not cause resets.

Are you actually sure you are seeing "resets" and "reboots" and not just unexpected code execution ?
 

erco

Senior Member
Reply yes, revert no. The Hulk may revert to himself when he ceases to be angry, but the word implies a change in state to a previous condition/version/owner etc. :)
Correct. Just don't revert back, since that gets you nowhere...

"Let's do a quick 360 and get the heck outta here!"
 

MPep

Senior Member
Also, make sure you have enough capacitance on the power supply lines. Try 100 - 470uF, together with 100nF.
 

Anobium

Senior Member
It was a power supply issue. Caps addded.

Thank you!

May I edit the posting title to better reflect the root cause of the problem?
 

MPep

Senior Member
No problems. Sometimes the simplest explanations are the ones that get overlooked. We're all guilty of that somewhere along the way. :)
But then, how would we learn??
 

westaust55

Moderator
It was a power supply issue. Caps addded.
Great to read that the problem is fixed by adding some capacitors.

While some of us do build circuits without the decoupling capacitors and get away with it, it does prove to be the solution on many occassions.
In saying the above, I often assemble initial circuits on a bread board and may omit the decoupling capacitors.
Then when it comes to transfering the circuit to a more permanent board as a matter of course I DO add some decoupling caps.
This is so that I do not end up experiencing problems at a later date and end up "scratching my head" trying to find the cause of problems.

So while some members state they do not use decoupling capacitors it is good practice to ensure they are included in circuits.
 
Top