Hi, all
There is something strange happening, and i would like your help in trouble-shooting it ....
The following code-snippet works perfectly as expected anywhere between 20 and 130+ times, but then 'hangs' - for want of a better word.
client.println("EHLO CharlieD"); /* say hello (statement after helo is needed but irrelevant)*/
delay(little);
Serial.println("0"); // debuggering ...
while (client.available()) {
char c = client.read();
Serial.print(c);
}
Serial.println("EHLO CharlieD"); // debuging
client.println("MAIL FROM:<charlesdavis@iuncapped.co.za>"); // identify sender
delay(little);
Serial.println("1"); // debug...
below is the part of the debuggering report(via Serial.print...) which shows me that when the system hangs, it was busy with the ... client.println("MAIL FROM: ..... statement/instruction. It appears to me that it never returns from this to get to the Serial.println("1"); debug line, although it will do so fine for, sometimes, 130 or more e-mails.
Sending 1-hour-report ... 62
0
220 mail.iuncapped.co.za ESMTP Postfix
250-mail.iuncapped.co.za
250-PIPELINING
250-SIZE 20000000
250-ETRN
250-AUTH CRAM-MD5 DIGEST-MD5 PLAIN LOGIN
250-AUTH=CRAM-MD5 DIGEST-MD5 PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
EHLO CharlieD
Have any of you in the 'Brains Trust' seen this before ? I will gladly provide more info if you need it, I don't want to over-share with stuff which may be un-necessary ...
Thanks (in anticipation) for all your help 
The application is an Arduino Duemilanove, AtMega328 with the ETHShield SD, and it's job is to monitor the charge-state of a battery at a remote location, and report voltage once an hour if it is within limits, and up this to once a minute when the voltage falls below a threshold. For testing, I have it sending an e-mail each minute, and this is how I found the 'hang' ( It is easier to wait 130 minutes than 130 hours )
Charlie
Have you tried placing the "Serial.println("1"); // debug..." before the delay statement?
Chances are that you're right, but this way you'll be sure about it.
Next, when you try to send the mail, is the connection still up? Say the connection is down, and you try to send the string, what happens?
What does the server reply look like when it doesn't hang?
Yes, I tried that too - didn't report it here, since I also thought it was highly unlikely that the 'delay..' would hang ... I even used 'Serial.print(".5");
One other data-point is - EVERY time it hangs, the pin 13 LED (between the aref and gnd pins on the wiznet module) stays dimly lit -- it does flash momentarily for each transmission when the thing works, ans is otherwise off .... I haven't put a 'scope on it yet, so don't know if the wiznet is pulling it low or if the '328 is pulsing it faster than my eye can see, at arround 50% duty-cycle .. might be interesting/relevant to know .. I will check it out later.
Another thing -- when it is hung, the reset button will not even bring it back .. only thing to do it cycle the power - this is true weather it is on an external PSU or running from the USB ...
Thanks for the interest
C
bubulindo:
Next, when you try to send the mail, is the connection still up? Say the connection is down, and you try to send the string, what happens?
What does the server reply look like when it doesn't hang?
Sorry - next answers here ... all the lines beginning with a 3-digit number are server-responses, the others are debuggering comments of mine
The full debug message for a 'working' message is here
Sending 1-hour-report ... 5
0
220 mail.iuncapped.co.za ESMTP Postfix
250-mail.iuncapped.co.za
250-PIPELINING
250-SIZE 20000000
250-ETRN
250-AUTH CRAM-MD5 DIGEST-MD5 PLAIN LOGIN
250-AUTH=CRAM-MD5 DIGEST-MD5 PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
EHLO CharlieD
1
250 2.1.0 Ok
2
250 2.1.5 Ok
3
354 End data with <CR><LF>.<CR><LF>
4
5
6
7
8
9
250 2.0.0 Ok: queued as 5065C7D848E
a
221 2.0.0 Bye
Done & Dusted !
The battery voltage is 14.0000000000 over 53 readings
b
Here is a bit more of the same block of code in the first messsage - left out to save bandwidth in the first post, but does work to ensure the server is there ...
time_to_report = false;
count += 1;
Client client(server, 25);
Serial.println("");
Serial.print("Sending 1-hour-report ... ");
Serial.println(count, DEC);
delay(little);
if (client.connect()) // not sure if connect or connected !!! -- old comment, answer is 'connect' ..
{
// Serial.println("connected");
client.println("EHLO CharlieD"); /* say hello (statement after helo is needed but irrelevant)*/
delay(little);
Serial.println("0"); // debuggering ...
CharlieD:
One other data-point is - EVERY time it hangs, the pin 13 LED (between the aref and gnd pins on the wiznet module) stays dimly lit -- it does flash momentarily for each transmission when the thing works, ans is otherwise off .... I haven't put a 'scope on it yet, so don't know if the wiznet is pulling it low or if the '328 is pulsing it faster than my eye can see, at arround 50% duty-cycle .. might be interesting/relevant to know .. I will check it out later.
Another thing -- when it is hung, the reset button will not even bring it back .. only thing to do it cycle the power - this is true weather it is on an external PSU or running from the USB ...
Are you actually using pin 13 in your software?? If you're not, then it shouldn't flash. Meaning that something fishier is present.
If you are, looks like the program is stuck somewhere where the pin is used.
Then the reset not bringing che chip back to life...
What power supply are you using?? USB?
bubulindo:
Are you actually using pin 13 in your software?? If you're not, then it shouldn't flash. Meaning that something fishier is present.
If you are, looks like the program is stuck somewhere where the pin is used.
Then the reset not bringing che chip back to life...
What power supply are you using?? USB?
I am not using pin 13 LED at all, I assumed the ethernet lib did ...
I get the same results (or lack thereof ) when using USB or a wall-wart, the same 12V regulated one I use for my DSO ... which I will now hook-up to see what is for what on pin 13 .. it definately blinks quite fast during each transmission
Here is a picture of the activity on the pin13 when the system 'hangs' ... and I am NOT using pin 13 at all in my code
![]()
Aaah, ok, how does one attach pictures - it is of the screen of my DSO, in jpg format ?
ok - it works diffrently to other forums, just dosen't show in 'Preview' ..
OK, just to let those who might be interested know how this got fixed ....
Normally, it is good practice to build code slowly, and test often ... however, since I was stuck with this 'crashing' issue, I decided to add more of the functionality I wanted in the final version - one of the features I wanted is to write to and read from the SD card .... what one needs to do here is disable the W5100 when accessing the SD, and vise-versa ... and here is where the fix came to light.
It is necessary to DISABLE the SD card when using the W5100 EVEN THOUGH YOU ARE NOT USING THE SD CARD IN THAT CODE !!! so, yes - adding complexity solved the problem ...
Cheers