Pages: [1]   Go Down
Author Topic: Have I fried my chip or is something else going on?  (Read 1557 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Full Member
***
Karma: 0
Posts: 111
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hello All

I have a home made arduino board using a ATMega328P.

I have attached 3 servos and a Sharp IR sensor.

The servos are powered by a seperate power supply to the microcontroller and Sharp IR sensor.

The power supply in both cases is a bank of 4 AA rechargable batteries.

This seemed to work fine but my programming was not up to scratch, resulting in the robot crashing.

Last night, following a lot of testing to determine optimum sensor angles and distances where I was getting good results I suddenly started having some really bizzarre results.

LED continues to blink as programmed in the setup loop.... Other times it may read in a command (I use serial to send commands to the chip) once and then hang. Other times the board seems to reset itself. other times I get complete gobbldygook output on the serial console. I even loaded a new, simple blink sketch. The Arduino IDE reported the upload succesfull but the LED was still blinking in the pattern as specified in the initial program's setup loop as mentioned above. After removing and re-applying the power to the Arduino clone it seemed the new blink sketch had succesfully uploaded as the blink pattern was as specified by the new sketch.

Can anyone give me any idea why this may suddenly be happening? Have I fried my chip or could there be another cause? Is it possible my power supply is flat and therefore not providing enough current? How would I measure this given I have rechargeable batteries and apparantly the voltage they give does not degrade as it does in standard disposables?

Any advice would be appreciated.
Logged

Offline Offline
Full Member
***
Karma: 0
Posts: 111
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi KE7GKP

I was under the impression that the voltage supplied by rechargables does not degrade, so my bank would still measure about 4.8V even with fairly flat batteries, or am I mistaken?

Anyway, is this bizzarre type of behaviour typical for an underpowered system?

Cheers
Logged

United Kingdom
Offline Offline
Tesla Member
***
Karma: 227
Posts: 6637
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I don't think you've fried your chip, it's most likely due to the battery voltage now being too low to run reliably at 16MHz. You might wish to run your processor at 8MHz or less so that it can work reliably at lower voltages. This will also lower the current consumption so that the batteries last longer.
Logged

Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

0
Online Online
Shannon Member
****
Karma: 214
Posts: 12440
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

It seems simple enough to just measure the power supply voltages with a meter. You cannot do this kind of experimenting without a meter. Fortunately, you can get them for very low prices.

Rechargeable batteries run on the low side anyway (for example 1.2V vs. 1.5V primary cell) and four of them in series may only be 4.8V. So it seems quite possible that you have run them down below the reliable voltage level.  I would consider revising the power scheme.

Old NiCd cells were 1.2V, newer NiMH are more like 1.35V, fading down towards 1.2V as they discharge - 4 NiMH cells is usually fine for "about 5V".  Shouldn't crash till the cells are totally discharged.  But of course if you don't know measure the voltage all bets are off!
Logged

[ I won't respond to messages, use the forum please ]

Global Moderator
Dallas
Offline Offline
Shannon Member
*****
Karma: 209
Posts: 13024
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
I have a home made arduino board using a ATMega328P

What fuse settings did you use?

Quote
Shouldn't crash till the cells are totally discharged

Or until they discharge to 4.3 volts at which point the Brown Out Detector takes control and resets the processor.
Logged

Offline Offline
Full Member
***
Karma: 0
Posts: 111
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

This is really strange.

The thing is it was working fine for a long time, running the servos and scanning and returning the values...

Not sure what the fuse settings are...

I have disconnected everything except my input button (which toggles states) and my serial read process and it croaks on the serial read. Sometimes I get serial output that looks like it is puking the program code... My error or output strings are in clear text and then a lot of gobldy-gook special chars which I think may be the printable version of the byte? code in the controller.

Logged

Offline Offline
Full Member
***
Karma: 0
Posts: 111
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

fwiw attached is the settings.

I have tried running it using the power from my usb port and even that chokes where in the past it was no problem smiley-sad

Code:
C:>avrdude -v -c avrispv2 -p m328p -P COM5 -U hfuse:r:high.txt:r -U lfuse:r:low.txt:r

avrdude: Version 5.10, compiled on Jan 19 2010 at 10:45:23
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "C:\program files\WinAVR\bin\avrdude.conf"

         Using Port                    : COM5
         Using Programmer              : avrispv2
         AVR Part                      : ATMEGA328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page
      Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65     5     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0 0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0 0 0x00 0x00

         Programmer Type : STK500V2
         Description     : Atmel AVR ISP V2
         Programmer Model: AVRISP
         Hardware Version: 15
         Firmware Version Master : 2.10
         Vtarget         : 0.0 V
         SCK period      : 150.9 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e950f
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DA
avrdude: safemode: efuse reads as 5
avrdude: reading hfuse memory:

Reading | ################################################## | 100% 0.01s

avrdude: writing output file "high.txt"
avrdude: reading lfuse memory:

Reading | ################################################## | 100% 0.01s

avrdude: writing output file "low.txt"

avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DA
avrdude: safemode: efuse reads as 5
avrdude: safemode: Fuses OK

avrdude done.  Thank you.
Logged

Offline Offline
Full Member
***
Karma: 0
Posts: 111
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

More information.

I removed all the components, and have slowly been adding them again, and the following procedure seems to be causing the weird behaviour even though I am not yet calling it in my code!! It is just present in the code.

Am I misusing pointers etc? I wish to return the values in bestAngle and bestDistance to the caller.

Code:
//Will scan for path and return angle and distance
void scanForPath(int* bestAngle, int* bestDistance) {
  writeDebug( "scanForPath bestDistance: " + String(*bestDistance) );
stop(); //stop bot just in case
neckServo.write(90); //look foreward
int distance;
//scan left first
for (int i=90; i > 10; i--) {
neckServo.write(i);
delay(25); //delay 25 millis to allow servo to arrive at position
distance = getSensorDistance();
if ( distance < *bestDistance ) {
  writeDebug("Better distance right: " + String(distance));
*bestDistance = distance;
*bestAngle = i;
}
}
for (int i=10; i < 170; i++) {
//scan to the right
neckServo.write(i);
delay(5); //delay 5 millis to allow servo to arrive at position
distance = getSensorDistance();
if ( distance < *bestDistance ) {
  writeDebug("Better distance left sweep: " + String(distance));
*bestDistance = distance;
*bestAngle = i;
}
}
} //scanForPath(int* bestAngle, int* bestDistance) {
Logged

Global Moderator
Dallas
Offline Offline
Shannon Member
*****
Karma: 209
Posts: 13024
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

fwiw attached is the settings.

Code:
C:>avrdude -v -c avrispv2 -p m328p -P COM5 -U hfuse:r:high.txt:r -U lfuse:r:low.txt:r

         AVR Part                      : ATMEGA328P

avrdude: Device signature = 0x1e950f
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DA
avrdude: safemode: efuse reads as 5

http://www.engbedded.com/fusecalc/

Brown Out Detector set to 2.7V.  When the battery voltage reaches that level, the processor will be reset.
Logged

Global Moderator
Dallas
Offline Offline
Shannon Member
*****
Karma: 209
Posts: 13024
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Am I misusing pointers etc?

From the set of symptoms and the fact that you have some fairly long strings in your code snippet I suspect you are exhausting SRAM.
Logged

Offline Offline
Full Member
***
Karma: 0
Posts: 111
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Am I misusing pointers etc?

From the set of symptoms and the fact that you have some fairly long strings in your code snippet I suspect you are exhausting SRAM.


Hi Coding Badly

Could you please clarify what you mean by exhausting SRAM?

Should I attempt using much shorter debug strings? Is SRAM specific to holding strings?

Cheers
Logged

Left Coast, CA (USA)
Offline Offline
Brattain Member
*****
Karma: 361
Posts: 17301
Measurement changes behavior
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Is SRAM specific to holding strings?

SRAM is where all your variables, arrays, and strings are stored and manipulated. The Arduino Uno board has but 2K bytes of SRAM, the Mega board 4K. There is a way to store read only strings in FLASH memory where your program is stored, using PROGMEM functions.

http://www.arduino.cc/playground/Main/PROGMEM
Logged

Offline Offline
Full Member
***
Karma: 0
Posts: 111
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Thanks for that retro.

I may attempt to reduce my usage of strings... see if that helps.
Logged

Global Moderator
Dallas
Offline Offline
Shannon Member
*****
Karma: 209
Posts: 13024
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset


A follow-up to retrolefty's suggestion ... this library will simplify your effort...
http://arduiniana.org/libraries/flash/
Logged

United Kingdom
Offline Offline
Tesla Member
***
Karma: 227
Posts: 6637
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi AgeingHippy,

1. I can't tell whether you are misusing pointers without seeing the code you use to call function scanForPath.

2. Does the code still malfunction when you comment out the two writeDebug lines? If you might be exhausting RAM then you should avoid using the String class.
« Last Edit: August 15, 2011, 08:25:15 am by dc42 » Logged

Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

Pages: [1]   Go Up
Jump to: