Instability of 18M2

BillBWann

Member
I have recently started using the 18M2 but have had instability problems with it in that it appears to be constantly resetting itself. I have reduced my test circuit down to a single 1k resistor & LED on pin c.0 and the standard 10k/22k programming resistors. I've also placed a 0.1uF capacitor across the power supply pins.

I've loaded the following program which simply outputs a message, flashes the LED 5 times and then ends.

Code:
#picaxe 18m2
#no_data

sertxd ("Started Flash",cr,lf)

for b0=1 to 10
toggle c.0
pause 500
next b0

end

'endf: sleep 1: goto endf
Initially, I found when operating this circuit from a switch mode 12 volt supply that was well filtered and reduced to 5 volts via a 7805, that touching the Serial In pin (C.4) with my finger, caused the program to restart. This was solved by the Disconnect command but I wondered why I needed it. In fact, I found all the input pins needed a resistance to ground of less than 10k to keep them low. All of these problems disapeared if I operated the circuit from 4 rechargable batteries or if I earthed the negative supply from the switch mode supply - but again, I'm not sure why I need to do this and its not always convenient to have an earth connection.

However, I now find that even when I operate this circuit from a battery, the circuit resets itself every 2602 seconds. It does this even if the programming cable is removed (ie I see the LEDs flash every 2602 seconds) so it isn't being reset by the programming cable.

If the program is changed slightly by replacing the "end" statement with a "endf: sleep 1: goto endf" statement, it still resets but now at intervals of 235 seconds. By changing the sleep interval variable to "sleep 100", the reset interval changed to 267 seconds. However if I replace the sleep command with a pause command (ie "endf: pause 2300: goto endf"), the resetting doesn't seem to occur (or if it does its interval is longer than 24 hours).

I've repeated the above with 2 different 18M2's and got similar results from each. As a sanity check, I also ran the equivalent code on an 08M and as expected it didn't reset.

What's going on? I must be doing something wrong because I can't see any reference to anyone else having these re-setting problems with the 18M2 but its not obvious to me what.

Thanks

Bill
 

hippy

Technical Support
Staff member
Touching the Serial In pin seems to be triggering what looks to the PICAXE to be a download request. This would seem to be an issue with the power supply or EMI from that with your finger picking up something and injecting it into the Serial In - Similar to 'mains hum' when touching an audio amplifier's input. I think we'd need to see the full circuit diagram and know what all the connections were to analyse further.

As to the other resets we will investigate.
 

Pauldesign

Senior Member
All of these problems disapeared if I operated the circuit from 4 rechargable batteries or if I earthed the negative supply from the switch mode supply
You might have a bad ground connections or your reset switch might be intermittently shorting to Gnd.

its not always convenient to have an earth connection.
:eek:

Really. Well, to me it's a must if operated from a PSU other than a battery.

Also posting your full source codes might help a lot. Note, the internal silicon connections and firmware on the 08M and 18M2 are different, hence different internal and physical features; so it might work on a 08M and not on an 18M2.

Just for interest, how does your program behave on the simulator; on an 18M2 and on different PICAXEs.

If u've one, a good sanity check might be on a physical 18X or on an 18 series which unfortunately have all been discontinued.:(
 

russbow

Senior Member
I am not quite sure what your problem is.

Your program works OK in the simulator and runs perfectly on my 18m2 proto board.

It flashes the LED 5 times then stops. Exactly what you told it to do. If you want it to repeat change the code to

Code:
#picaxe 18m2
#no_data

sertxd ("Started Flash",cr,lf)

[B]Main:[/B]

for b0=1 to 10
toggle c.0
pause 500
next b0

[B]goto main[/B]

end
So maybe it's not resetting, maybe just ending. :rolleyes:
 

MartinM57

Moderator
...me too. But maybe the receiving end of the sertxd put some timestamp on the screen.

But the question remains about whether it was repeatable, i.e pretty much every 2602 seconds or just observed once.

And with the problem of resets by touching pins and dodgy earths it might not be anything to do with fundamental instability of the PICAXE or its firmware.
 

russbow

Senior Member
...but did you wait 2602 seconds to see if they flashed again - as BillB is reporting?
Nah, the program said end, so I did.

...me too. But maybe the receiving end of the sertxd put some timestamp on the screen.
It didnt for me.

And with the problem of resets by touching pins
Don't know if the M2 pins were in or out. never leave an in floating.

Pretty high gain devices so mains hum is probable.
 

inglewoodpete

Senior Member
I have reduced my test circuit down to a single 1k resistor & LED on pin c.0 and the standard 10k/22k programming resistors. I've also placed a 0.1uF capacitor across the power supply pins.
It's not clear to me: is the 0.1uF cap as close as possible to the PICAXE power pins?

Initially, I found when operating this circuit from a switch mode 12 volt supply that was well filtered and reduced to 5 volts via a 7805, that touching the Serial In pin (C.4) with my finger, caused the program to restart.
I am suspicious of the wiring of the 22k and 10k resistors. Unless you are in a very low humidity environment they should adequate to keep the Serial In pin stable.

Is the circuit stable with the programming lead plugged in? Which programming lead are you using?
 

Technical

Technical Support
Staff member
We'll investigate this for you. But as your experiment suggests this only occurs when you use sleep ('end' is just a permanent form of sleep) we suggest you just use the command 'stop' instead of 'end' within your program and see if the problem is solved.
 

BillBWann

Member
Thanks Technical & Hippy for looking into this further. I was originally designing a more complicated device than this test circuit and I had a lot of instability problems - initially from the power supply but later from a section of my program where I needed a 5 hour delay. It was difficult for me to understand what was happening so I devised various test circuits and programs to investigate it.

My concern is how many other commands may cause the program to reset unexpectedly. As I noted in my first post on this, the program is resetting after only 4 minutes when using sleep - and yes, I don't have that much patience so I did use a timestamp program to monitor the chip and it was quite regular and did keep resetting at those time intervals quoted.

Does this mean, we should never use sleep even for relatively short delays if we don't want to risk having a premature reset? And are there any other situations where a premature reset may occur?

I'm also still a bit surprised that I need to have the switchmode supply earthed when I have the input pins tied to the negative supply via 10k resistors. I haven't really investigated this aspect very much but the supply looks good when displayed on my CRO and my trusty old 08M doesn't appear to be upset by it - ie it doesn't reset and the input pins appear to be quite stable when tied down (or up) with a 10k resistor.

Thanks again to all who have commented.

Bill
 

MartinM57

Moderator
I'm also still a bit surprised that I need to have the switchmode supply earthed...
I think we're going to need diagram to get to the bottom of this. Reference points for earth, accidental or purposeful earthing through programming cable/PC, 2 mains-wire insulated power supply bricks etc are all in the mix and more detail is needed (if you want to pursue the matter). I can't understand why it would affect a 18M2 and not an 08M.

I'm sure Technical will be back on the reset case soon - they're very good you know ;)
 

hippy

Technical Support
Staff member
In terms of PICAXE commands unexepectedly causing reset; none should and we are investigating this issue. We test all PICAXE firmware but testing can never be exhaustive nor test all possible combinations of code. Something which may be an issue which only materialises after 45 minutes or longer is harder to spot and less likely to be caught.

It's a bit like an engine bolt which may fall out after an engine has been run flat-out for a full day as the engine block heats up and expands. In other cases it's not a problem and you'd not see a problem except in those circumstances, and maybe not always then. That issue would not be indicative of any other potential issues, except in the existential sense that there can always be unexpected issues. That's the key point which gets made when discussing safety critical applications.
 

BillBWann

Member
The switch mode power supply is this- http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=390195556664. I can hear Dippy saying "you get what you pay for" and as you can see I didn't pay much. However for my purposes, I think it will work out fine. The project I use it for controls another device via an SPI interface and as the other device is grounded, the 18M2 works fine as long as I keep it connected to the other device, use the disconnect command and don't use any sleep commands.

The conversion to 5 volts simply consists of the 4.7uF capacitor on the output of the adapter and 2*0.1uF capacitors on the 5 volt side of the 7805 with one of the capacitors connected directly to the 18M2 power supply pins. The whole circuit is located inside the housing of the adapter replacing the 12 volt lighter socket so it is in very close proximity to the switch mode supply.
 

Dippy

Moderator
You get what you pay for!

Hapyy? :)


I don't know whether your problem is PSU related.
Is your 5V regulator bit as suggested by regulator Manufs?

And, by the way, HF spikes will shoot through most regulators without touching the sides. Decoupling with good dielectric caps can, in some cases, be crucial.
... anyway, just letting you know for future reference.
You have to be careful with sw/mode ..... sometimes you need to add good components and often use an oscilloscope to look at nasties.
 
Top