Troubleshooting unwanted picaxe reset

[GreenLeader]

Its rather a long story - I think it would take a few A4 pages to explain what I am doing in detail - so I'm going to start with an abbreviated version - hopefully 1/3 of an A4 page.

This is my first PICAXE project, though I have been playing around for a few months now, testing & learning. I have a 40X1 and AXE022 project board + an AXE033 board with LCD, real time clock and an EEPROM. I have had no problems trying out various things with above devices.

I am now having some problems when I add other things on breadboard to link into the above. I have 3 separate EEPROMS on breadboard but I'm using only the 4k7 resistors on the AXE033 for my i2c. I also have a FRM010 and separate 4x20LCD - working fine. So the 2x16LCD on the AXE033 has been removed. But I am retaining the AXE033 to get to the clock and the EEPROM, whilst I trial things.

My test program is a loop (repeats about 5s) that writes some data to each of the 4 EEPROMS, then reads it back and displays it on an LCD so I can verify that the read/write was good.

The picaxe is resetting itself whenever the i2c (SCL/SDA) lines to the AXE033 are connected (in order to access the DS01307 clock and 24LC256 EEPROM that live on the AXE033).

When I test the program without connecting the i2C lines from AXE022 to AXE033 it runs indefinitely without incident. Of course I just get 65535 back from the reads because the i2c lines are not connected, but this is as expected.

But when I connect the i2c lines, things start out fine, and I can see that the write/read is good. But after about 10 loops, the PICAXE resets and starts again.

I thought I might be drawing too much power from the 5V regulator on the AX022, but I checked and am only drawing about 40mA. The regulator should be good for 100mA. Checking the 5V supply at various points with a multimeter does not show any signs of voltage dropping - steady at 4.96V.

My next step would be to stay away from the AXE033 altogether and put the 4k7 resistors and the 4th EEPROM onto breadboard, but I haven't tried that yet.

That's where I ran out of ideas and the forum comes in

I can post the actual code if it would help. Could anyone shed some light on typical causes of resetting, what sort of things I might do to trace it. I've searched the forum but have not found anything that really seems to fit my symptoms...


many thanks.

 

[BrendanP]

Put 100n and 10n caramic caps across the V and ground pins as close to the picaxe as possible. Put a 10n ceramic cap from the reset pin to ground.

Ive had similar problems with multiple IC's running in a circuit. Other than that Ive got no idea.

 

[hippy]

The first step may be in identifying every combination which works and doesn't work. I'd strongly suggest using the breadboard Eeprom's with their own 4K7 pull-ups and a disconnected AXE033 as the next test.

Length of signal path and where pull-ups are can affect the I2C bus. It may even help to have pull-ups on the breadboard AND on the AXE033.

The other thing to do is to identify where ( and then determine why ) the program stops. Code your program so it stops when reset after the first time, use SERTXD before every I2C command and log what happens - The last thing done before a reset may help pinpoint what's actually causing the problem. Don't forget to add a SERTXD after every I2C command or you may start thinking it's an I2C command causing a problem when it isn't necessarily ...

Eeprom $00,(0)

PowerOnReset:
  Pause 2000
  SerTxd( " RESET" )
  Read $00,b0
  Do : Loop While b0 <> 0
  Write $00,$FF
  SerTxd(" STARTED" )

MainLoop:
  :
  Do
    SerTxd( " I2CREAD ..." )
    I2cRead ....
    SerTxd( " OK" )
    :
  Loop

You can add SerTxd's after every label and before every subroutine call and return ( and anywhere else for that matter ). Download and test the program a few times to check it does stop in a particular place, then it's a case of analysing the trace you have. You may have to add more SerTxd's to show important information when you get to a particular place but you can also take out SerTxd's which turn out not to be relevant as you narrow your focus down on where the bug is, hardware or software.

Knowing why something doesn't work can be more useful than just fixing a problem; has it really gone away or have you just been lucky, will a similar problem materialise later ? Even if moving the pull-ups seems to fix the problem it may be worthwhile removing them and trying the above anyway. Perhaps not in this case; a scope and looking at the difference in signals would probably be a better way to confirm the problem and its resolution.

The key helper in debugging is in finding a reproducable bug. Once that's achieved it's much easier to analyse the why's and wherefore's of that.

 

[womai]

In addition to decoupling the power supply (100 uF electrolytic capacitor anywhere on your board, and a 0.1uF ceramic capacitor close to the Picaxe) it's also a good idea to separately decouple the reset pin from the power supply. That way sudden spikes/drops in the supply (which you can't see with a voltmeter, only with a fast enough oscilloscope) can't trigger a reset.

Connect the reset pin through a resistor to the supply voltage. Also connect a ceramic capacitor between the reset pin and ground (place it as close as possible to the reset pin). There are recommended values by Microchip, but in my experience a 10 kOhm resistor and between 10nF and 100nF capacitance works well.

Another possibility - look at your code, maybe your program branches to a different place the moment it reads something useful from the I2C bus? I had a case where I thought the Picaxe reset itself for no good reason, only to find out that a serin command timed out and wanted to jump to the timeout label - which was not defined, so it jumped to the program's beginning instead, which very much looked like a reset. To distinguish that from a true reset, verify if the variable values (e.g. b0) change between before and after the alleged reset - a true reset will set them to zero, in my case above they would keep their value even if it was nonzero.

Wolfgang

 

[BCJKiwi]

ONLY ONE set off pullups for the entire i2c BUS!!!!!

Ensure every device that is connected to the bus is;
a) powered,
b) complies with the setup (i2cslow etc).

If you are testing different devices and are not using some of them, disconnect them from the bus completely, just lifting the power connection is not enough.

The AXE-022 has pullups on board so those should be the only ones in the circuit. They will be good for i2cslow, not i2cfast!

 

[GreenLeader]

Thanks for the suggestions.
I've tried Hippy's sertxd tracing approach and have established that the "reset" always occurs when I issue one of my hi2cin commands (not always the same one). The reset always occurs after sertxd *8.1, *8.2 or *8.3 commands, never the first one (*8.0).

..
hi2csetup i2cmaster,%10100000,i2cfast,i2cword
..

sertxd("*8.0 read from EEPROM")
hi2cin [%10100000],0,(b16,b17)
sertxd("*8.01 read from EEPROM")
pause 50
sertxd("*8.1 read from EEPROM")
hi2cin [%10100010],0,(b18,b19)
sertxd("*8.11 read from EEPROM")
pause 50
sertxd("*8.2 read from EEPROM")
hi2cin [%10100100],0,(b20,b21)
sertxd("*8.21 read from EEPROM")
pause 50
sertxd("*8.3 read from EEPROM")
hi2cin [%10101100],0,(b26,b27)
sertxd("*8.31 read from EEPROM")
pause 50
sertxd("*9 end read from EEPROM")
pause 500

I've tried increasing the pause from 5 to 50 before the next hi2cin, to no avail.

I've also tried with i2cslow, also to no avail.

Next thing to try is disconnect the AXE-022 completely and see if that works...

I'll let you know what happens!!

 

[hippy]

That does seem to prove it's got something to do with accessing the I2C bus.

To me it suggests something is collapsing the power supply ( a short from SDA or SCL to +V, the 4k7 pull-ups too low in value, zero-R link fitted ? ) or the power supply doesn't have enough current to handle it when the I2C devices are enabled. There could be some circuit shrt from SDA or SCL to Reset.

Why the fault moves around is a mystery, a hard short would be in a consistent place.

Unplugging I2C devices to see what happens then is the next step as you suggest doing.

 

[Technical]

When you connect to the AXE033 you are connecting to a DS1307.

This part doesn't like going fast and can get confused if you do. Its quite possible it could lock up and freeze the i2c bus. So code such as

hi2csetup i2cmaster,%10100000,i2cfast,i2cword

will definately cause an issue with it.

Dooes the fault occur when the DS1307 is physically removed from the AXE033? If not it proves this is where the problem lies.

 

[GreenLeader]

I think I've finally found the fault - turned out to be my own stupidity

I had the AXE033 set up to be used in serial mode, so I had Jumper J1 open. To use it in i2c mode, it has to be closed. Simple as that. Pays to re-read the manual now and then!!

 

[Dippy]

It's OK GL, this happens a lot i.e. not reading the manual. And confession cleanses the soul

At least you didn't blame a 'faulty PICAXE' which is many people's first line to excuse their own , how do I say this nicely, reluctance to read.

A lesson learnt. Remember the old saying: "Look Before you Leap".
I wish I could remember that too sometimes....