Picaxe-18x Losing my program after powerdown

[twiereng]

Greetings all,

I've used several Picaxe-18x processors for robots and have not had this problem before. When I power down my circuit I loose the program. I have the 18x connected to two L298N H-brige circuits powered at 12v. I have a 7805 regulator to power the 18x and 5 v. supply on the L298Ns. I only have a few LEDs as the L298N load, so no motor noise. I'm using clip leads and noticed a little sparking, probably because of 2000uF caps on the 12 v line and 1500uF on the 5 v line. I have a .1uF right across the 18x power pins. If I power down and come right back up, I seem to usually preserve the program. If I wait 5 minutes the program is gone. I thought the caps might be causing a surge, so I removed all but 470 uF on the 5 volt line. Still does the same thing. What do I need to do to filter the 18x? I must be missing something here.

Thanks, Theron Wierenga
Muskegon, Michigan, USA

 

[moxhamj]

That seems very odd. The program is stored in eeprom which is very stable (usually!). I am wondering if the program still is there, but it isn't running due to interference or some other problem. Where is the reset pin connected? And what is the circuit on the download pin? And do you a spare 18X that you could swap into the circuit - that will help determine if it is the chip that is the problem, or the circuit.

 

[hippy]

It would generally be considerd to be impossible for a PICAXE to simply lose its program after it has been downloaded which points to something affecting the PICAXE so it appears it does not work. Two things there; the program itself or the attached hardware.

The first test would be to download a very simple program, say -

Pause 2000
SerTxd( "Starting ...", CR, LF )
Do
Pause 1000
SerTxd( "Working!", CR, LF )
Loop

and watch that using the Programming Editor Terminal function. If that keeps showing "Working!" after power-offs then it's not losing its program there's something related to the rest of the code.

 

[twiereng]

My response

Thanks for the responses.

Dr Acula

Reset is tied to 5 v. by a pullup with a switch to ground for reset. By download I suspect you mean Seial In. I have the standard 22k and 10k as shown in Manual 1. Tried a second 18x, same results.

hippy

Ran you program, works OK. So now I begin to suspect my program. It not much, just read input pins, all five, and then outputs differnt values depending on input. The LED setup I have on the L298N circuits tells me it working as I planned. Here's the code - have I done something dumb?

symbol inport = b0
symbol iforward = 0xC8
symbol ireverse = 0xB0
symbol left = 0xD0
symbol right = 0xA8
symbol alloff = 0x00
symbol up = 0x03
symbol down = 0x05

top:
let inport = pins '0x40 0x05
'debug b0

if bit7 = 1 then jump1
if bit6 = 1 then t1 ' forward

if inport = 0x00 then t10 ' alloff
if inport = 0x02 then t2 ' left
if inport = 0x01 then t3 ' right
if inport = 0x04 then t4 ' reverse
if inport = 0x06 then t4
if inport = 0x05 then t4

jump1:
if bit6 = 1 then t11 ' up
if inport = 0x80 then t10 ' alloff
if inport = 0x82 then t10
if inport = 0x81 then t10
if inport = 0x84 then t12 ' down
if inport = 0x86 then t12
if inport = 0x85 then t12
goto top

t1:
let pins = iforward
pause 10
let pins = alloff
pause 4
goto top
t2:
let pins = left
pause 10
let pins = alloff
pause 4
goto top
t3:
let pins = right
pause 10
let pins = alloff
pause 4
goto top
t4:
let pins = ireverse
pause 10
let pins = alloff
pause 4
goto top
t10:
let pins = alloff
goto top
t11:
let pins = up
pause 10
let pins = alloff
pause 4
goto top
t12:
let pins = down
pause 10
let pins = alloff
pause 4
goto top


Thanks, Theron

 

[moxhamj]

Can't see anything wrong with the code. I guess that just leaves the 'brute force' solution, which is to take Hippy's working program and then add bits of your program till it falls over. I've had faults like this before. You know it should work. You have the simplest program. You end up isolating it to one line of code that you know works, and the only possible explanation is that the power supply must be shorted when that line of code runs, and then you turn over the board and notice the blob of solder causing a short, and yet you had stared at the board for hours and not seen it. It probably won't be that exact fault, but first step is to isolate the line of code. You might write a little subroutine to call each of those outputs in turn and display which one is being called with a sertxd, then pause a few secs, then do the next one.

 

[BeanieBots]

I've observed "strange" behaviour when PICAXEs are powered on/off from boards with large amounts of capacitance such as you have.
The problem stems from the supply not going to 0v when switched off.
SOME of the PICAXE internals can still run at voltages as low as 1.2v but SOME start to fail at around 2v. A single internal transistor state can be set with a supply as small as 0.6v.
If power is switched off, allowed to drop to about 3v and then re-applied, it is quite likely that things will pickup from where they left off. If the supply is allowed to drop to 2v, then results will be unpredictable. Taking the supply right down to 0.6v will gaurantee a full reset.

 

[evgerven]

POR - power On Reset?

Fortunately Picaxes are quite forgivable recovering from low power and second: the Picaxe can run from very low power!

These 2 characteristics are kind of contradictional and can cause problems in some situations.

In the past, when I first got involved in digital circuitry, it was good practice to force a reset after power on.

Usually a simple RC combination on the reset pin will do the trick, making the reset high for a short time after power-up because the capacitor is empty .
But hey! This is also where the brown-out function is for!

Some guidelines:
- always use the build-in brown-out functions on picaxes unless you take you take own measurements to prevent
'not very-powered-down' situations.
- Use the resetpin where available for a true power-on reset using discrete components (R/C combiantion).
- If no external reset is available then power the picaxe using a transistor that shuts down when the voltage is below a fixed voltage. (Brown-out detection) and comes up only after the powersource is stabilised.
- make sure no input/output connections are providing power to the picaxe during the reset-state.
- take especially care where multiple powersources are involved (common practice when driving motors,relays etcetera)
Because the load (motor) is usually incative at power down, the capacitors in that part of the powersupply will not drain fast and possibly provide power to the picaxe through high state output pins. To prevent this, use a diode as buffer to the power stage to make sure current can only leave the picaxe.
- In 'critical' designs a fast discharge on power-down can be advisable.
This way all remaining power will be actively drained from all powersupplies in your design and a fast power-off-on cycle is possible.
On request I can make some diagrams to eliminate such parasitair power sources and clarify above guidelines.

Erik

 

[hippy]

Assuming the program is there and the code runs after power-off and on again, there are only two possibilities; what it does is not observable ( stopping motors when already stopped say ) or it's not getting to a routine which would cause it to do anything.

I am going to guess it is stuck in the 'top:' loop, never getting out of it with any of those IF statements. I could be wrong but that's where I'd start. I note the DEBUG; does that reveal anything, an 'inport' / 'b0' value which isn't what is expected ? You could also try using SERTXD("b0=",#b0," ").

As well as peculiar reset latch-ups it is also possible to get I/O pin latch-up and it could be that your pins are not reading correctly after some turn-on's. That can also happen if you have floating inputs. If you put that SERTXD above just before the main loop ending 'goto top' the Terminal will only show when there's been a failure and that may help identify what is going on.

 

[westaust55]

twiereng,

while I recognise that you are new, can I suggest that you read the README FIRST thread at the start of the Active section of this forum.
See: http://www.picaxeforum.co.uk/showthread.php?t=7679

Then try to implement some formatting/indenting to your code to make it easier to read. Have a look at the example I have just done for Pekari in post 9 of this thread: http://www.picaxeforum.co.uk/showthread.php?t=10708

I am sure that you will agree it is easier on the eye for you to read as it is certainly for others here when they try to help you.

 

[Technical]

Have you tried masking off only the desired inputs in b0?
let inport = pins & %11000111

What about this condition
%00000111 '($7)
or
%00000011 '($3)
... not accounted for (also $83 and $87)???

 

[westaust55]

AS an extension of what Technical has already flagged, here is a modified section of code.
I have presumed that the untested cases are to return to the top label but easy enough to change. This version will also save 17 bytes of code.

top:
     LET inport = pins & %11000111 '0x40 0x05
     'debug b0

     IF bit7 = 1 THEN jump1
     IF bit6 = 1 THEN t1 ' forward

     inport = inport & %00000111            ; extracts the lowest 3 bits for a value from 0 to 7
     ON inport GOTO t10, t3, t2, top, t4, t4, t4, top

jump1:
     IF bit6 = 1 THEN t11 ' up
     inport = inport & %00000111            ; extracts the lowest 3 bits for a value from 0 to 7
     ON inport GOTO t10, t10, t10, top, t12, t12, t12, top

     GOTO top

 

[alpacaman]

I absolutely agree with technical. Last week I posted a very similsr problem where the progtram worked fine after I programmed it but once power was recycled it no longer would read the inputs. Hippy suggested masking the input which fixed everything.

 

[twiereng]

OK, got it, thanks to all of you

Isn't it always a dumb mistake? I put SERTXD("b0=",#b0," ") in the top loop and get a return of 0x08, oops that isn't valid. It's those unused input bits. I replaced my input with the suggested let inport = pins & %11000111 and this seems to solve the problem.

I think the power on reset is also a good idea. Brown out shouldn't be a problem as I will be using a car battery for power.

I'll try putting my power caps back in now.

Thanks to all of you for the thoughtful responces.

Regards, Theron

 

[hippy]

I put SERTXD("b0=",#b0," ") in the top loop and get a return of 0x08, oops that isn't valid. It's those unused input bits.

Which is interesting though because that's pin RA3 of a 16F88, Serial Out of a PICAXE-18X which should normally idle low for SERTXD. Reading a pin which is an output should return what that pin is set to and I thought it needed quite some external oomph to override an output and read it differently.

One would normally expect RA3 ( 0x08 - Serial Out ), RA4 ( 0x10 - Serial In ) to both read low, RA5 ( 0x20 - Reset ) to be high ( but perhaps forced low by the fuse configuration ), so it shouldn't be necessary to mask out RA3 or RA4.

Also, why is this seemingly only intermittent ?

This is the second recent post which has been fixed by masking; I'm wondering if there's been some Firmware change in the 18X which has affected things ? It may be a long standing thing and I'll admit it's been a while since I used "=pins' and I've usually masked anyway.

Thought : Does "=pins" make PORTA entirely an input just before it reads, which would allow the external hardware to set what RA3 reads as ?

 

[Technical]

No change, the firmware has always just read the whole porta directly. You would see the same results with a peek of porta. Reading a pin that is set as an output is not going to always give you the actual output status of that pin - that's a 16F series PICmicro quirk (hence the extra latch registers in the 18F series - to read the status of the output you read the latch not the actual pin). It looks here like the value is floating around.
Therefore the 'missing' inputs (3,4,5) should always be masked out. We'll mark an 'automatic' mask as something to possibly look at for the next firmware update.