Problem Random BX24 Resets

Started by harrybstoner September 7, 2005
I've spent several hours trying to figure out why my BX24 is resetting.

I had the BX24 circuit running on a breadboard with zero resets for
many months. I had a PCB made up and soldered the components on. The
BX24 resets occasionally on the PCB. Somewhat randomly. No program
changes moving it from the breadboard to the PCB.

I am still not sure if it could be a reset line being pulled low, or
if it's a voltage drop (the manual says the processor will be reset if
the voltage drops below 4.75V).

I've measured resistance to as many of the connections as I can think
of to ensure that there are no bad solder joints, etc.

One guess is that maybe I don't have big enough filter caps for the 5V
supply (7805 regulator). I think they are 47uf. But if that's the case
why would there be no resets on the breadboard? Also have .1uf cap
close to the power pins.

My clue here is that if I power on a speaker system connected to the
same power bar as my electronics, the BX24 is resetting almost 100% of
the time (but 0% of the time on breadboard). That makes me thing the
voltage might be dropping. I don't have a storage oscilloscope to
capture this easily. Maybe I can try eyeballing it quickly on the
screen ...

Searching the archives, there was a post by mikey_1_4 that was
unanswered and I thought would be good to know:

"Is there a status bit or method which can indicate the source of a
reset? Weather the BX24 was reseted from a watchdog timer or the
reset signal?"

I measured the total current draw of everything and it was between
170ma and 305ma. The heat sink on the 7805 was warm but not scalding hot.

Is the voltage on the reset line treated like a 1 or 0, e.g. voltage
above 1.4V is a logic 1 and below a logic 0 (or similar). I read a
voltage over 4.7V on that line. At what voltage on the reset line will
the processor reset?

Just wondered if anyone has any wisdom on this. I will continue to
check for flaky solder connections, etc. Normally I read about 4.98V
on the BX24 power pin.

Thanks a lot.

Harry



I suppose that you have to determine one of three sources of the
reset.

Low power [your battery is going dead and the BX-24 drops the
voltage, then the battery tries to get going again and fails]

A broken BX-24 [try switching it to a different power supply and a
different context - not the same board and maybe just run a test
program of somesort.

Interference from outside power surges or oscillations [Florescent
lights play havoc with certain electronics, motors starting up, or
switching lights on and off in an automotive application'

Since you built a board, I would expect you have a Low power
condition due to a short circuit someplace. I just built a BX-35
board and had to spend three days to get the LED on the board to
light up without anything plugged in. First I had a cold solder
joint. After I fixed that I burned up a regulator with a short
circuit, then I had a low voltage due to a tiny, tiny solder bridge.

Finally I have gotten it working and let is sit on for 2 days to make
sure I won't hurt the BX-35.

Before I plug the ICs in, I will test all the pins for proper
voltages or in the absence of power, proper continuity.

I don't think you will find any 'flag' in any microcontroller that
keeps track of why things reset, unless you create an 'add-on'
routine. Reset usually wipes the RAM and goes to a designated
address in the ROM to start over. All data is lost.

Maybe a capacitor is no good, maybe a diode is backwards, maybe you
forgot to put a 470ohm resistor on an LED [I have done all of these
and more].

--- In basicx@basi..., "harrybstoner" <tedstoner@1...> wrote:
> I've spent several hours trying to figure out why my BX24 is
resetting.
>
> I had the BX24 circuit running on a breadboard with zero resets for
> many months. I had a PCB made up and soldered the components on. The
> BX24 resets occasionally on the PCB. Somewhat randomly. No program
> changes moving it from the breadboard to the PCB.
>
> I am still not sure if it could be a reset line being pulled low, or
> if it's a voltage drop (the manual says the processor will be reset
if
> the voltage drops below 4.75V).
>
> I've measured resistance to as many of the connections as I can
think
> of to ensure that there are no bad solder joints, etc.
>
> One guess is that maybe I don't have big enough filter caps for the
5V
> supply (7805 regulator). I think they are 47uf. But if that's the
case
> why would there be no resets on the breadboard? Also have .1uf cap
> close to the power pins.
>
> My clue here is that if I power on a speaker system connected to the
> same power bar as my electronics, the BX24 is resetting almost 100%
of
> the time (but 0% of the time on breadboard). That makes me thing the
> voltage might be dropping. I don't have a storage oscilloscope to
> capture this easily. Maybe I can try eyeballing it quickly on the
> screen ...
>
> Searching the archives, there was a post by mikey_1_4 that was
> unanswered and I thought would be good to know:
>
> "Is there a status bit or method which can indicate the source of a
> reset? Weather the BX24 was reseted from a watchdog timer or the
> reset signal?"
>
> I measured the total current draw of everything and it was between
> 170ma and 305ma. The heat sink on the 7805 was warm but not
scalding hot.
>
> Is the voltage on the reset line treated like a 1 or 0, e.g. voltage
> above 1.4V is a logic 1 and below a logic 0 (or similar). I read a
> voltage over 4.7V on that line. At what voltage on the reset line
will
> the processor reset?
>
> Just wondered if anyone has any wisdom on this. I will continue to
> check for flaky solder connections, etc. Normally I read about 4.98V
> on the BX24 power pin.
>
> Thanks a lot.
>
> Harry



> ... I don't think you will find any 'flag' in any microcontroller
that keeps track of why things reset...

A bold statement, G.

From the Atmel AT90S8535 dox:

"MCU Status Register - MCUSR
The MCU Status Register provides information on which reset source
caused an MCU reset.
Bits 7..2 - Res: Reserved Bits
These bits are reserved bits in the AT90S4434/8535 and always read as zero.
Bit 1 - EXTRF: External Reset Flag
After a power-on reset, this bit is undefined (X). It can only be set by
an external reset. A watchdog reset will leave this bit unchanged. The
bit is reset by writing a logical one to the bit.
Bit 0 - PORF: Power-on Reset Flag
This bit is only set by a power-on reset. A watchdog reset or an
external reset will leave this bit unchanged. The bit is reset by
writing a logical one to the bit."

I do not know if this data remains after BasicX reboots, however. Tom


--- In basicx@basi..., "harrybstoner" <tedstoner@1...> wrote:
> I've spent several hours trying to figure out why my BX24 is resetting.
>
> I had the BX24 circuit running on a breadboard with zero resets for
> many months. I had a PCB made up and soldered the components on. The
> BX24 resets occasionally on the PCB. Somewhat randomly. No program
> changes moving it from the breadboard to the PCB.
>
> I am still not sure if it could be a reset line being pulled low, or
> if it's a voltage drop (the manual says the processor will be reset if
> the voltage drops below 4.75V).
>
> I've measured resistance to as many of the connections as I can think
> of to ensure that there are no bad solder joints, etc.
>
> One guess is that maybe I don't have big enough filter caps for the 5V
> supply (7805 regulator). I think they are 47uf. But if that's the case
> why would there be no resets on the breadboard? Also have .1uf cap
> close to the power pins.
>
> My clue here is that if I power on a speaker system connected to the
> same power bar as my electronics, the BX24 is resetting almost 100% of
> the time (but 0% of the time on breadboard). That makes me thing the
> voltage might be dropping. I don't have a storage oscilloscope to
> capture this easily. Maybe I can try eyeballing it quickly on the
> screen ...
>
> Searching the archives, there was a post by mikey_1_4 that was
> unanswered and I thought would be good to know:
>
> "Is there a status bit or method which can indicate the source of a
> reset? Weather the BX24 was reseted from a watchdog timer or the
> reset signal?"
>
> I measured the total current draw of everything and it was between
> 170ma and 305ma. The heat sink on the 7805 was warm but not scalding
hot.
>
> Is the voltage on the reset line treated like a 1 or 0, e.g. voltage
> above 1.4V is a logic 1 and below a logic 0 (or similar). I read a
> voltage over 4.7V on that line. At what voltage on the reset line will
> the processor reset?
>
> Just wondered if anyone has any wisdom on this. I will continue to
> check for flaky solder connections, etc. Normally I read about 4.98V
> on the BX24 power pin.
>
> Thanks a lot.
>
> Harry

One possibility.

If you are drawing 170 - 300 mA, you are probably driving something,
turning something on and off. This causes changes in current on the
+5 VDC and GRD buses. The result is commonly known as ground spikes
or L-di/dt transients.

The solution is to run a dedicated +5 VDC and GRD bus for the BX24 and
other logic circuitry and separate +5 VDC and GRD for the heavier
load. These are connected at the lowest impedance point available,
which is probably the output of the 7805.

The important thing is not to be switching currents in the same leads
that furnish power to the BX24 and other similar logic.

This is probably just what you don't want to hear!

Peter Anderson
http://www.phanderson.com/basicx/


Thanks for the info on the MCUSR bits Tom. Didn't really think that
info would be accessible - I should have checked myself first. I will
try and check those bits on start up and flash led's differently
depending upon the reset type. At least then I'll know for sure why
it's resetting.

Harry

--- In basicx@basi..., Tom Becker <gtbecker@r...> wrote:
> > ... I don't think you will find any 'flag' in any microcontroller
> that keeps track of why things reset...
>
> A bold statement, G.
>
> From the Atmel AT90S8535 dox:
>
> "MCU Status Register - MCUSR
> The MCU Status Register provides information on which reset source
> caused an MCU reset.
> Bits 7..2 - Res: Reserved Bits
> These bits are reserved bits in the AT90S4434/8535 and always read
as zero.
> Bit 1 - EXTRF: External Reset Flag
> After a power-on reset, this bit is undefined (X). It can only be
set by
> an external reset. A watchdog reset will leave this bit unchanged. The
> bit is reset by writing a logical one to the bit.
> Bit 0 - PORF: Power-on Reset Flag
> This bit is only set by a power-on reset. A watchdog reset or an
> external reset will leave this bit unchanged. The bit is reset by
> writing a logical one to the bit."
>
> I do not know if this data remains after BasicX reboots, however. > Tom



--- In basicx@basi..., "pha555" <pha@p...> wrote:
> --- In basicx@basi..., "harrybstoner" <tedstoner@1...> wrote:
> > I've spent several hours trying to figure out why my BX24 is
resetting.
(snip)

>
> One possibility.
>
> If you are drawing 170 - 300 mA, you are probably driving something,
> turning something on and off. This causes changes in current on the
> +5 VDC and GRD buses. The result is commonly known as ground spikes
> or L-di/dt transients.
>
> The solution is to run a dedicated +5 VDC and GRD bus for the BX24 and
> other logic circuitry and separate +5 VDC and GRD for the heavier
> load. These are connected at the lowest impedance point available,
> which is probably the output of the 7805.
>
> The important thing is not to be switching currents in the same leads
> that furnish power to the BX24 and other similar logic.
>
> This is probably just what you don't want to hear!
>
> Peter Anderson
> http://www.phanderson.com/basicx/

Thanks Peter. From what you've said and what I read elsewhere on
ground spikes now, it sounds like I should isolate the grounds, or at
least connect the two parts at one place only. I do switch relatively
high currents through NPN transistors. My PCB layout is not great. I
have fat ground traces but the traces are daisy chained (I know this
is less than optimal).

If the ground traces from the transistor emitter leads are segregated
from the ground traces to the logic (e.g. BX24 and other logic chips)
as far back as possible then it sounds like I may have less problems.

This explanation might also explain why I don't have the problem on
the breadboard.

If I physically cut a ground trace with an exacto knife, is that
sufficient to isolate the parts, or will there still be some sort of
capacitive effects? Do I need to cut these trace far apart (e.g.
several mm)?

Thanks a lot.

Harry


--- In basicx@basi..., "harrybstoner" <tedstoner@1...> wrote:
> --- In basicx@basi..., "pha555" <pha@p...> wrote:
> > --- In basicx@basi..., "harrybstoner" <tedstoner@1...> wrote:
> > > I've spent several hours trying to figure out why my BX24 is
> resetting.
> (snip)
>
> >
> > One possibility.
> >
> > If you are drawing 170 - 300 mA, you are probably driving something,
> > turning something on and off. This causes changes in current on the
> > +5 VDC and GRD buses. The result is commonly known as ground spikes
> > or L-di/dt transients.
> >
> > The solution is to run a dedicated +5 VDC and GRD bus for the BX24 and
> > other logic circuitry and separate +5 VDC and GRD for the heavier
> > load. These are connected at the lowest impedance point available,
> > which is probably the output of the 7805.
> >
> > The important thing is not to be switching currents in the same leads
> > that furnish power to the BX24 and other similar logic.
> >
> > This is probably just what you don't want to hear!
> >
> > Peter Anderson
> > http://www.phanderson.com/basicx/
>
> Thanks Peter. From what you've said and what I read elsewhere on
> ground spikes now, it sounds like I should isolate the grounds, or at
> least connect the two parts at one place only. I do switch relatively
> high currents through NPN transistors. My PCB layout is not great. I
> have fat ground traces but the traces are daisy chained (I know this
> is less than optimal).
>
> If the ground traces from the transistor emitter leads are segregated
> from the ground traces to the logic (e.g. BX24 and other logic chips)
> as far back as possible then it sounds like I may have less problems.
>
> This explanation might also explain why I don't have the problem on
> the breadboard.
>
> If I physically cut a ground trace with an exacto knife, is that
> sufficient to isolate the parts, or will there still be some sort of
> capacitive effects? Do I need to cut these trace far apart (e.g.
> several mm)?
>
> Thanks a lot.
>
> Harry

A relatively simple fix is to cut the V+ and GRD traces right at the
BX24. Then run separate leads using hookup wire from the 7805 to V+
and GRD to power the BX24. Easier said than done, but I suspect it
will solve your problem.

Hope this helps.

P H Anderson
http://www.phanderson.com/basicx/


PLEASE forgive me, having read the whole thread I seem to have

[1] been very wrong
[2] not completely understood the orginal problem.

I seem to have gotten overconfident with my postings and I will try not
to jump in where I have not much to offer.

--- In basicx@basi..., Tom Becker <gtbecker@r...> wrote:
> > ... I don't think you will find any 'flag' in any microcontroller
> that keeps track of why things reset...
>
> A bold statement, G.
>



I appreciate your input. As follow up on this item, although the Atmel
processor does provide clues as to the type of reset, I was not able
to extract anything meaningful from the BX24 for this.

I added code near the start of my program to read Register.MCUSR and
try and decide if it was power on reset (POR), external reset (EXT) or
watchdog reset (WD).

In all cases, the MCUSR value was &H01 (hex 01), indicating POR, even
when I did an external reset via grounding the reset line. I simply
flashed the onboard LEDs the number of times equal to the read MCUSR
value. It always flashed once, indicating the &H01 (POR) value.

I can only presume that the BX24 operating system itself already
touched this flag before my program received control. Or am I missing
something?

Thanks.

Harry

--- In basicx@basi..., "G. Kramer Herzog" <hwanghetw@y...> wrote:
> PLEASE forgive me, having read the whole thread I seem to have
>
> [1] been very wrong
> [2] not completely understood the orginal problem.
>
> I seem to have gotten overconfident with my postings and I will try not
> to jump in where I have not much to offer.
>
> --- In basicx@basi..., Tom Becker <gtbecker@r...> wrote:
> > > ... I don't think you will find any 'flag' in any microcontroller
> > that keeps track of why things reset...
> >
> > A bold statement, G.
> >



--- In basicx@basi..., "pha555" <pha@p...> wrote:
> --- In basicx@basi..., "harrybstoner" <tedstoner@1...> wrote:
> > --- In basicx@basi..., "pha555" <pha@p...> wrote:
> > > --- In basicx@basi..., "harrybstoner" <tedstoner@1...>
wrote:
> > > > I've spent several hours trying to figure out why my BX24 is
> > resetting.
> > (snip)
> >
> > >
> > > One possibility.
> > >
> > > If you are drawing 170 - 300 mA, you are probably driving something,
> > > turning something on and off. This causes changes in current on the
> > > +5 VDC and GRD buses. The result is commonly known as ground spikes
> > > or L-di/dt transients.
> > >
> > > The solution is to run a dedicated +5 VDC and GRD bus for the
BX24 and
> > > other logic circuitry and separate +5 VDC and GRD for the heavier
> > > load. These are connected at the lowest impedance point available,
> > > which is probably the output of the 7805.
> > >
> > > The important thing is not to be switching currents in the same
leads
> > > that furnish power to the BX24 and other similar logic.
> > >
> > > This is probably just what you don't want to hear!
> > >
> > > Peter Anderson
> > > http://www.phanderson.com/basicx/
> >
> > Thanks Peter. From what you've said and what I read elsewhere on
> > ground spikes now, it sounds like I should isolate the grounds, or at
> > least connect the two parts at one place only.
(snip) >
> A relatively simple fix is to cut the V+ and GRD traces right at the
> BX24. Then run separate leads using hookup wire from the 7805 to V+
> and GRD to power the BX24. Easier said than done, but I suspect it
> will solve your problem.
>
> Hope this helps.
>
> P H Anderson
> http://www.phanderson.com/basicx/

Thanks Peter. Unless I can pull a rabbit out of my hat I will probably
be trying this.

Harry