Blinking LED 13

Somehow I managed to do this on a Pro Mini 3.3v It continues even after a power cycle.
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1234338562

It is difficult or impossible to upload a new sketch because of the watchdog timer.
How can I have caused this error? I don't think it's the code alone, it's been running for hours on different hardware.
I think somehow it's related to a hardware mistake made by my client.
In the above link, the problem was recreated, but it's easy to fix by power off, then loading a new sketch.

Mine is not so easy. Is this possible? How did it happen? Theories?

After many experiments I have determined my code works perfectly ON MY HARDWARE regardless of user switch input.
Still it fails (13 blinking) on my clients Pro, EVEN WITH NO WIRES CONNECTED except RAW (battery 4.12v) and Gnd.
Of course I tried no wires here too, on 3 different types of boards, including the exact same one.
I have greatly simplified the code to track this down, the above is still true.
I have managed to reload a new sketch on the "broken" hardware.

Yet a blank sketch runs fine with no wires connected (of course).
And a simple blink runs too.
It must be something in my code.

I'm going to double verify the above facts then paste my code here, hang on.

It works perfectly (does nothing)
You can print x0,y0,z0 if you have an ADXL345 mine does that too, but only when it's connected :wink:

#include <Wire.h>
#define X0 0x32
#define X1 0x33
#define Y0 0x34
#define Y1 0x35
#define Z0 0x36
#define Z1 0x37

int i,j,k,ii,x0,y0,z0=0;
long sec;

void setup(){
delay(1000);
Wire.begin();
//Serial.begin(9600); 
Wire.beginTransmission(0x1D); //ADXL345 0x53 if SDO is Gnd
Wire.write(0x2D);// POWER_CTL
Wire.write(0x09);// measurement mode, 4hz wakeup
Wire.endTransmission();
//while(factive())
//there is no "13" search for it yourself
//try it yourself there is no hardware required to make it crash!
//no loop() needed it crashes in here:
initxyz();
//pinMode(13,OUTPUT);
//sec=millis()/1000;
}
void loop(){
}

byte requestByte(char dir){
Wire.beginTransmission(0x1D);
Wire.write(dir);
Wire.endTransmission();
Wire.requestFrom(0x1D,1); // request 1 byte
//while(Wire.available())
return(Wire.read());
}
int getDir(byte dir){ //0-2 is xyz
int i;
if(dir==0)i=requestByte(X0)+(requestByte(X1)<<8);
if(dir==1)i=requestByte(Y0)+(requestByte(Y1)<<8);  
if(dir==2)i=requestByte(Z0)+(requestByte(Z1)<<8);  
//delay(20);
return(i);
}
void initxyz(){
x0=y0=z0=0;
for(i=0;i<20;i++){
x0+=getDir(0);
y0+=getDir(1);
z0+=getDir(2);
delay(30);
}
x0/=20;
y0/=20;
z0/=20;
}

If your sketch enables the watchdog timer you can work around that by powering it off, holding down Reset, powering it on, holding down Reset until the sketch starts to upload, and then release Reset. That will go straight into the bootloader without running the existing sketch.

Nick, that fits the circumstances on my clients Pro.
But how did I enable the watchdog timer?
Why not on my (same) hardware with the same code above?

But how did I enable the watchdog timer?

You coded it to do so?

Some of the bootloaders turn the watchdog off immediately, some don't. So it might be a bootloader issue, coupled with your code that turns the watchdog on.

You can see from my code above that I didn't mean to do that. How can I fix it? This is difficult since I didn't do it :wink:
It is hard to believe that this happens on my clients Pro Mini 3.3v without any wires attached. But I trust him and it is repeatable.
(except Raw 4.12v and Gnd)

In the first version, not posted, there was no reference to pin 13 at all, we used pin 2 for LED. Yet 13 was blinking. That's how I knew it was the watchdog timer and it matched the other thread linked above. Now I use pin 13 so we can troubleshoot without connecting anything to the board. Same blinking results on his Pro. No LED output on mine without ADXL connected (same code). It works as planned when I go back to original code enabling LED when it detects activity. His blinks the same, with or without any wires connected. With or without the code referring to pin 13. Mine never blinks 13, except when it's supposed to. I'm getting repetitive, just trying to be clear. Bueller?

sbright33:
Yet 13 was blinking. That's how I knew it was the watchdog timer and it matched the other thread linked above.

How do you know it is the watchdog? That sketch doesn't use it. It might just be resetting. For example, due to insufficient voltage.

Great idea! What is the acceptable range on RAW on 3.3v Pro?

Seems more likely to be too low, then too high, because it worked briefly. Batteries don't usually go up. Can USB charge it past 4.2v while it's connected? Is it getting warm because it's high? There's not much else it can be, since that's the only pin connected. Assuming the same hardware and code is used for each of us.

What other reason, besides wrong battery voltage, can it reset?

Now it works for a few minutes before it crashes in his circuit. Mine continues to work, never fails. Same circuit. Different FTDI.
Here's the strange part: When he does a power cycle by unplugging the battery it immediately starts flashing 13 again.

When he leaves it unplugged for 20 minutes, it then works for a few minutes...
The same is true with no connections to Pro.
Is it possible the board is bad? He's tried >1.
Please help!

Can anyone think of a possible explanation for this strange behavior?

One thing that I've run across in several circumstances, that has not been mentioned here, is HEAT. Sometimes a board can appear to work fine for a while, then suddenly stop working or behave strangely, because the chips reach a certain temperature. Since that temperature may vary from location to location, it might work for you when it does not work for the client. Swapping boards can help, but it does not necessarily rule out this scenario, because the two boards may have been produced with specific parts (e.g., resistors or capacitors) from different manufacturers, with different tolerances or heat ranges. I don't know if this is your issue, but I just wanted you to consider the possibility.