next topic »

[on:]

I made a board with a mega328, GPS Module, a few LED's and SD Card on it and I notice that when the battery still has plenty of power (3.9V (LiPo) with the mega328 operating at 3.3V internal 8 MHZ clock source) it will enter what I think is a brown out reset loop.  I think the culprit may be the fact that the entire board is routed with 8mil traces.  I have .1uF capacitors next to each Vcc pin and 2 10uF capacitors at the output of the buck/boost converter.  I don't have an oscilloscope so I can't really see what is happening.  Based on experience, would 8mil traces likely be the culprit?

[Reply #1 on:]

The brown out voltage is not related to the supply voltage it is fixed. See the data sheet.

[Reply #2 on:]

The brown out voltage is not related to the supply voltage it is fixed. See the data sheet.

Right.....brown out voltage is 2.7V based on the arduino fuse bit settings.  I'm just wondering if the 8 mil traces could cause a significant voltage drop (from 3.3V to below 2.7V) when, for example, a pin connected to an LED turns on?  If you need more information, please let me know.

[Reply #3 on:]

No I would not consider there would be sufficient voltage voltage drop on a narrow trace. Mainly because there is very little current flowing.

[Reply #4 on:]

I would measure the voltage and see. Also your sketch, which we can't see, might have bugs.

[Reply #5 on:]

No I would not consider there would be sufficient voltage voltage drop on a narrow trace. Mainly because there is very little current flowing.

That is what I kind of figured when I first made the board, but it just seems weird that it works fine when the battery is fully charged but when it gets down to about 3.8 - 3.9V, it just starts entering a reset loop.  The buck/boost converter is putting out 3.3V so it isn't even having to boost the voltage at that point.  I thought that perhaps I didn't have enough capacitors next to the Vcc pins on the mega as another possibility.

[Reply #6 on:]

I would measure the voltage and see. Also your sketch, which we can't see, might have bugs.

Unfortunately I don't have a scope so I can't see what the voltage is at the moment that it resets.  I am sure the sketch is buggy, but it does run when the battery is fully charged.  It makes it hard to debug when I can't figure out if the reset condition is due to bugs in the sketch or if it is a hardware design problem.

[Reply #7 on:]

Change the fuse to brownout at a lower voltage and see what happens.

[Reply #8 on:]

8 mil traces, buck-boost converter. OOF! Is this on the same pcb? I don't know which part
you're using, but see the picture, same idea for buck-boost,

[Reply #9 on:]

Change the fuse to brownout at a lower voltage and see what happens.

To do that, do I just change this line in board.txt:

Code:

atmega328bb.bootloader.extended_fuses=0x05

to

Code:

atmega328bb.bootloader.extended_fuses=0x06

and then burn the bootloader again?

[Reply #10 on:]

8 mil traces, buck-boost converter. OOF! Is this on the same pcb? I don't know which part
you're using, but see the picture, same idea for buck-boost,

Well the traces dealing with the converter and charging circuit are all polygons.  So for instance, this is what the bottom layer looks like around the buck/boost converter (TPS63001DRCT) and the top layer is a solid ground plane with lots of vias stitching the two sides together.  The thick traces leading out from there are a revision that will go in the next board.  In the board that I am working on right now, they are thin traces but the polygons directly around that little SON10 package are all there.


converter by jg1996business, on Flickr

[Reply #11 on:]

To do that, do I just change this line in board.txt:

Code:

atmega328bb.bootloader.extended_fuses=0x05

to

Code:

atmega328bb.bootloader.extended_fuses=0x06

and then burn the bootloader again?

Yes that should do it. If you have a ISP programmer you shouldn't have to burn the whole bootloader. eg.

Code:

avrdude -c usbtiny -p m328p -U efuse:w:0x06:m

[Reply #12 on:]

To do that, do I just change this line in board.txt:

Code:

atmega328bb.bootloader.extended_fuses=0x05

to

Code:

atmega328bb.bootloader.extended_fuses=0x06

and then burn the bootloader again?

Yes that should do it. If you have a ISP programmer you shouldn't have to burn the whole bootloader. eg.

Code:

avrdude -c usbtiny -p m328p -U efuse:w:0x06:m

I just have the arduinoISP and the "burn bootloader" button on the arduino ide.

[Reply #13 on:]

Your proposed approach should work. Personally I use this sketch:

http://www.gammon.com.au/forum/?id=11638

You connect up the wires as shown (you don't need the SD card just to change fuses) and can then interrogate and change fuses through the serial monitor.

But, burning the bootloader should work OK. Assuming that the Arduino as ISP sketch actually does change the fuses.

[Reply #14 on:]

Your proposed approach should work. Personally I use this sketch:

http://www.gammon.com.au/forum/?id=11638

You connect up the wires as shown (you don't need the SD card just to change fuses) and can then interrogate and change fuses through the serial monitor.

But, burning the bootloader should work OK. Assuming that the Arduino as ISP sketch actually does change the fuses.

Thanks!  I may give that a try.