18m2+ buggy startup

[BITMOVER]

Here's one I never ran into before.

I have a 18M2+ loaded with code that works great. For simplicity let's just say it runs in a loop, looks for an input then outputs a tone burst.

Power up, burst out simple...
But sometimes when power is applied it just sits there doing nothing. Shut it down power it again and it's off and running forever.

The input on pin 16, (C.7) is a optotransistor and the pin swings between 0 and 4.9 when turned on and off. As for the power supply, it is a switch mode 24V wall wart, with an added 7805 regulator and big caps are before and after it with a .1uf accross the chip's power and ground. The 5V output is clean with no trash (I tried different power packs) and no inductors are being powered up at startup (looking for spikes)
The older 18M chip had pin 4 as a reset but the 18M2+ now designates that as C.5, and there is no reset. The two programming resistors are in place on pin 3. There are some inputs, C.0. C.1, C.2. and C.5 (the old reset) that are floating since they are not used. Am I missing something here? Since these are unused, do they need to be tied to gnd? It just looks like the chip is not starting since the loop is the first step in the program.

Any ideas or opinions will be appreciated. I have some more 18M2's on order in just case the chip is regressing back to it's carbon state.

Thanks,

Len

 

[Goeytex]

Without your code and a schematic, I'm afraid we are in the dark. A picture is worth a thousand words.

To troubleshoot you might add a sertxd at the beginning of the code so that you can see if the chip is starting and hanging further down the code.

#picaxe 18m2
#no data
#terminal 4800
pause 1000     '// give time for terminal to open
sertxd ("Picaxe is alive" ,cr,lf)

main:

  '// rest of code here
 
Goto main

If you see the message then the Picaxe is alive and there is likely something else causing the hang.

What does "Big caps" mean? 100uF, 5000uF? . You can over do it. On the input to the regulator you do not need a big cap, 1uf is more than enough, UNLESS there is a large switching load on the 24V supply. In this case a bulk capacitor should be located near the load. On the output of the regulator, 22uf - 100uf is more than enough UNLESS there is a relatively large switching load on the 5V supply rail. In this case, the large cap (bulk cap) should also be located near the load.

We really need to see an accurate schematic and your code.

 

[BITMOVER]

Thanks Goeytex,
After the weekend I'll add that code snip to the program, and add the "sertxd ("Picaxe is alive" ,cr,lf)" snip at other critical places if needed to watch the program flow.
I will get back with the results as well as posting the other information as soon as I can. There is a normally off LED that is used for something else that I can blink at startup to show that the processor started, and add the code as needed at various points.

The concerning thing is the intermittent nature of the startup. I can re-power one time after the fail to start and it runs without fail, but on the next 20 startups it may not fail at all. I would think, if it were a code issue, it would be more consistant, since the code doesn't change, and nothing is being dynamically altered or stored.
Also, there are no externally connected items that would require a delay to initialize, as in the terminal code that you offered.

We'll see soon after the weekend!

Thanks,

Len

 

[Goeytex]

Hi Len

In 5 of years messing about with hundreds of Picaxe & PIC chips I have not seen one fail in this manner for no reason. The most common cause of problems like this is a dodgy power supply or power supply related issues. These include bad grounds, cold / or bridged solder joints, or noisy peripherals. The chip is rarely bad. Although many times that seem to be the first thing suspected.

When a Picaxe actually fails, it is almost always a result of too much current, either due to to much applied voltage, applied reverse voltage, or an excessive load on an I/0 Pin. Sometime the failure is not immediately obvious.

One thing to check is the current through the +V supply line to the Picaxe. With NOTHING connected to the Picaxe except for the power and a 10K pot from the serin pin to ground, the current should be no more than about 2-4 milliamps ( depending upon clock speed). If the current is over about 5ma then something is suspicious. If >10 ma then there is a problem. I have one here that draws ~ 50ma as soon as it is connected. It's a battery killer. However it seems to work ok except that it occasionally will not accept a download and that serin gets garbage when operating over 4800 baud. This chip suffered an over voltage of 24V for a few seconds. So one thing to check is the quiescent current.

If this is a new project on a breadboard just getting started that's one thing. If it has been soldered up on a professional PCB and has been operating for 6 months with no problems and then just now started this behavior, that's another thing. So the more you can tell us, the better help you will get.

 

[BITMOVER]

Hi Goeytex,

The Picaxe is exonerated! It is doing exactly what it is told to do and the devil really is in the details. By looking inside the running beast I found where the gremlin lurked!

Things are getting good now...Here is what I found.
The input that will cause the program to exit the starting loop is actually a logic output (DV) from a touch tone decoder chip. I have used both, the now obsolete, UM9203 decoder and the SSI202P decoder since I have them on hand, and they are pin for pin compatible. If you look for either one, the same spec sheets pops up. I realize that the M8870 and it’s variants are more current decoders but they have a different pin out so they are not a drop in replacement.

So here is what's happening:
According to the specs, DV (Datavalid) goes high only with a valid DTMF tone, and then it goes low after the input tone stops, or, it can be set low with a high on CLRDV (Cleardatavalid.).

So the sequence is simply loop until DV is high, exit, go get the valid 4 bit DTMF byte then go do something else based on its value. DV should go low when the DTMF tone is released.

What Is happening is that on a cold start, the UM9203 sets the DV pin high, and it stays high, forever but there is no DTMF signal! The loop is then exited and it goes looking for the nonexistent DTMF byte. Since there is none it falls into an unplanned location and the program falls apart, because of this unanticipated error behavior.

When the power is reset, if the voltage does not go all the way to zero, before the decoder is powered back up, DV does not go high and the system works as intended. So, this problem happens only on a zero to Vcc power up! With the size of the caps I have in the power supply the voltage does not go to zero on a quick restart so the decoder always resets properly with a low DV. It will then run forever and DV only goes high with a valid DTMF present and then it is back low when the tone input stops, or if the tone is still present, CLRDV will set it back low..

Inside the decoder, the DV output is from a flip flop that apparently has flipped and not flopped on this odd startup??
Is it a buggy decoder? Well maybe since 4 out of 4 UM9203’s do the same thing, and none of the SSI’s exhibit this trait! The available specs and timing diagrams do not speak to this peculiar issue and all the application data shows CLRDV tied low, which I did in this design! None of the application data shows CLRDV being used as a handshake, but resetting the DV is mentioned in the specs.

So, the fix is to use only the SSI decoders, or patch an unused Picaxe I/O pin to the CLRDV input to force a reset as soon as the processor starts or to force a reset if the DV is high and no valid DTMF byte is decoded. I opted to do all three! So far I am still trying to make it misbehave, with either of the decoders, it works flawlessly.

I thank you again for your valuable and on target input and insight!

Len
(And if it does another trick, I'll be back!)

 

[srnet]

Read post #1 again, then look at the description you gave in post #5, describing the actual circuit you are using.

Could anyone but you have come up with the 'solution' based on the description in post #1 ?

 

[BITMOVER]

srnet,
Yes, you are right. No one could have determined the problem with the limited information I first provided, including you. I simply opened a dialog.
Since most faults are coding errors or incorrect parts application and connection, even if I posted the complete code and the schematic the answer would still be unknown.
When a component falls out of it's specified performance only by testing and observation can that be detected, it does not show on paper. Wild guesses are useless.

The suggestion made by Goeytex helped isolate this problem, and in my second post I said ... "After the weekend I'll add that code snip to the program, and add the "sertxd ("Picaxe is alive" ,cr,lf)" snip at other critical places if needed to watch the program flow. I will get back with the results as well as posting the other information as soon as I can. " I posted the results but did not post the rest since it seemed superfluous since the problem was located.

Because it first appeared that the Picaxe was not running, my initial observation fell in that direction. By watching the program flow it was obvious that my original impression was wrong and the results of that new observation and testing were later posted.

Len