20M program stops after 1 pass thru loop

[Dave E]

I needed a Picaxe to check battery voltages and I had a couple of 20M chips around so I used them. I wanted to check to see at what voltage NiMH batteries were at the end of their charge. I needed the picaxe to turn on loads, wait for the batteries to drain then turn off the loads. When I got up this morning, the 4 battery pack was reading 2.5 volts. The Picaxe did not turn off the load. I downloaded the data from my external datalogger and it verified that the load stayed on all night.

Upon investigating, it looks like the program started normally but only went one time through the DO loop and stopped. While testing, I added a TOGGLE 7 and a INC W5 and DEBUG to help troubleshoot. It turns out that as long as the TOGGLE 7 (led blink) is in the loop everything works OK (see attached program). If I REM out TOGGLE 7, the program goes through the loop once, DEBUG shows W5 to be 1 and that is it.

I also noted something else. With the program running, DEBUG does not update every time. DEBUG shows W5 to increment like this: 1, 2, 4, 6, 8, 10.... However, if I move the HIGH 7, 6, 5 command to inside the loop, W5 increments normally, 1, 2, 3, 4, 5, ...... Even with this command inside the loop, if TOGGLE 7 is removed, the program stops. Just for the heck of it I also changed CALIBADC10 to READADC10 13 but it did nothing different.

I verified most of this with another 20M.
Vsupply = 4.97 volts, PE = 5.3.1 (downloaded yesterday), 20M = 3.A.

I searched the forum but did not find anything that looked like this so if anyone has any info, I would like to hear it.

Dave E

 

[hippy]

Very odd, and I'm seeing the same. Replace DEBUG with SERTXD(#w5) and launch Terminal set to 4800 baud and it shows the loop is running, w5 is incrementing.

I guess there's some oddness with either data values or something which causes the Debug screen not to catch all debugging packets sent. I've made a note of the issue.

 

[Dave E]

Thanks for looking into it, Hippy.

Just to see what would happen, I replaced TOGGLE 7 with TOGGLE 4 (an output I am not using) and the programs runs. Remove it and the program stops.

Dave E

 

[cmast]

Could it be possible that when you turn on the loads they have not actually done their task (of turning on the load!) in time for you to be doing the first set of reads?.. If that were the case then the WORK and BITS would still be reading zero, which would then cause the IF statement condition to be met thus forcing the program to end in the first iteration?

What if you put a pause after the "HIGH 7, 6, 5 'TURN ON LOADS" statement.

Also - is that right the batteries are starting at 613 volts? :
Assuming the remark 'shut off VOLTAGE 440 = 4.40 V0LTS

 

[Dave E]

Thanks, cmast,
I removed some of the code before posting it (but tested it also) so that there would not be as much to look through. I did have a pause in several places including a 5 second pause after the TOGGLE command so that the voltage would stabilize before the ADC read eventhough the loads are resistive except the LED blink.

The 61380 is actually 613.8 * 100. 613.8 = 1023 * 0.6 (ref voltage)
Vsupply (bat_volt) = 1023 * ref voltage(0.6) / bits
To get 2 decimal places I multiply 613.8 by 100 before I start dividing so that if bat_volt is say 5.13 volts I get 513 instead of a whole number result of 5 only.

The other 2 outputs just send voltage through a resistor to ground and I did find an issue there. What I thought was a 330 ohm resistor was actually a 33 ohm resistor (need better lighting in my work area). However, after I removed that resistor, the problem remained. Namely, the program stops if I remove the TOGGLE command.

Thanks for your input.
Dave E

 

[cmast]

Ah I see, fair enough. Well the only thing I can think of now would be to try and 'prove' whether or not it is not a hardware/interpreter issue; maybe change the hard code value of '440' in the IF comparison statement to a variable and play about with different values?
Anyway good luck.

 

[Dave E]

Thanks for the help, cmast,
It looks like the IF statement is OK. I completely got rid of it and the program still seems to stop. Moving DEBUG to different places still shows that the DEBUG comunications stop. However, if I close the DEBUG window then re-open it, the count in W5 has changed. So it still looks like it may be a DEBUG communication issue.

Dave E

 

[sghioto]

Just to see what would happen, I replaced TOGGLE 7 with TOGGLE 4 (an output I am not using) and the programs runs. Remove it and the program stops.

This sounds similiar to a problem using the pulsout command on the 14M. As I remember Technical explained there was a firmware issue due the "strange" port layout and limited memory in the bootstrap. Could the 20M suffer from the same?

Steve G.

 

[Dippy]

Apologies for tiny digression..
Do we have a bugs and workaround page on this Forum? (and kept roughly up to date).
Then people could check firmware and if having a known problem they can read the workaround.
End of digression.

 

[Technical]

As hippy has already stated in post 2, the issue is simply that the debug window on the computer is not synchronising with debug data stream correctly for this one particular instance (set of particular data values) - it will be fixed in the next PE release. It is nothing to do with the firmware - the program is looping fine. Changing the output status of any other pin (it does not have to be 7) simply changes the value of the data sent via the debug stream, so you no longer have the particular non-working instance, and so debug kicks back into life on the computer screen.

You can easily work around by changing
debug

to something like
sertxd ("w5 =",#w5,cr,lf)

and you will see w5 correctly updating on screen.



All 20M firmware issues are listed in firmware.txt in the Programming Editor folder, and are:

*** PICAXE-20M ***
The PICAXE-20M firmware is implemented on a PIC16F677.
BASE FIRMWARE CODE:3
VA FIRST PUBLIC RELEASE. ROHS COMPLIANT
vB CORRECTED ISSUE WITH READ COMMAND
CORRECTED ISSUE WITH PULSOUT COMMAND

 

[Dave E]

Once again, thanks for your help, Technical and everyone.

Dave E