I have a similar problem on 3 Megas. I upload a sketch, which seems to upload as expected, about 4000 bytes. After the bootloader is finished, the sketch never gets out of the setup function. I have a serial message that transmits during setup and it only gets about 7 bytes out before setup starts over.
All I can see is that the RX led flashes briefly, the "L" led blinks, and the "on" led is on constantly. This cycle repeats about once per second or a bit faster.
These are knock off Megas with CH340 chips. I just noticed that my previous batch of Megas have 16mHz crystals and these have 12mHz crystals.
So I upload an FTDI version with a 16mHz crystal and I see the exact same behavior, except the TX led flashes (as expected since the first function in setup is a Serial.write(xxx))
Not a hardware problem. I found an old sketch with essentially the same Serial.write() application and it uploads and runs fine. Next step: commenting out segments of code...
I am not using the watch dog. I don't even have the library linked in. The anomaly is the same whether the Mega is connected via USB to my PC, or just powered by a wall wart. I suspect that it's possible the silk screen is wrong and the TX and RX LEDs are labeled backwards--there's obviously no external RX input when the Mega is on the wall wart.
As it turns out, the FTDI version flashes the TX LED instead of RX. And the "L" LED flashes faster, roughly 3/4 second, which would comport with a 16 mHz clock vice a 12 mHz clock. But the functional performance is identical, eg, I get 7 bytes transmitted serially, then reset.
Since the hardware functions fine with a different sketch (both the FTDI and the CH340 versions), I've drilled myself into a hole thinking that just the simple uploading of the sketch (reserving memory for small arrays and variables, etc.) has somehow triggered/modified a reserved something or other that screws up a Mega register. (you can see the desperation in this...)
sterretje, agree completely. I was just completing some experiments with delay() between statements to see what effect they had. Here's what I found:
The first delay(4000) works fine
Prior to inserting delays between the Serial.println() statements, the sketch output only three characters from the "this_file) string, then reset.
Adding the delays resulted in the text posted below the code.
Nothing below the line "//------end of version message---------" is working, despite all the added delay() statements.
I'm hoping that something about the Serial.write(control code) is doing the mischief.
// -------------------------------------------------------------
void setup() { // ---------------- Setup() ------------------
Serial.begin(9600); // Start serial communication at 9600 bps
pinMode(hold_SW,INPUT_PULLUP) ;
pinMode(w_w_open,INPUT_PULLUP) ;
pinMode(w_w_closed,INPUT_PULLUP) ;
pinMode(w_r_open,INPUT_PULLUP) ;
pinMode(w_r_closed,INPUT_PULLUP) ;
pinMode(r_r_open,INPUT_PULLUP) ;
pinMode(r_r_closed,INPUT_PULLUP) ;
pinMode(well_full,INPUT_PULLUP) ;
pinMode(well_high,INPUT_PULLUP) ;
pinMode(rain_full,INPUT_PULLUP) ;
pinMode(rain_high,INPUT_PULLUP) ;
pinMode(rain_low,INPUT_PULLUP) ;
delay(4000) ; // allow settling time
// ----------version message -------------
// Send version description is enclosed in a valid "V" format message.
// This allows the version to be read in the serial monitor, but
// also allows the network to throw the message away when the
// unit is installed in the system.
Serial.write(0xAA) ; //start byte
Serial.write("V") ; //"Version" message
Serial.write(0x0A) ; //line feed
Serial.println(this_file) ; //file name
delay(100) ;
Serial.println(descp) ; //description
delay(100) ;
Serial.println(ver) ; //version and date
delay(100) ;
Serial.write(0x04) ; //EOT
Serial.write(0x0A) ; //line feed
// ------ end of version message --------
delay(100) ;
// Serial.begin(9600); // Serial_1 is used between prime and backup
// clear the flags
FL_tanks[1] = 0 ;
FL_tanks[2] = 0 ;
FL_tanks[3] = 0 ;
FL_levels = 0 ;
//close all valves, halt on error
Serial.print("Now is the time") ;
delay(200) ;
// close_all() ;
// delay(10000) ;
// ack_msg('B') ;
// delay(4000) ;
// if(Valve_err)
Serial.print("Max time ") ;
delay(100) ;
Serial.write(Valve_max_time) ;
delay(100) ;
Serial.print("Valve Error ") ;
delay(100) ;
Serial.write(Valve_err) ;
delay(100) ;
while(1) {} ; // halt here until reset !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Here's the text from the serial monitor, from the code above:
⸮V
Water_fill_bkup_C
Backup ball valves
ver 1.0 12/29/17
⸮V
Water_fill_bkup_C
Backup ball valves
ver 1.0 12/29/17
⸮V
Water_fill_bkup_C
Backup ball valves
ver 1.0 12/29/17
FL_tanks has 4 elements (now). Five minutes ago it had 3. Duh. System is no long hanging. I think I'm going to have to tattoo a 0 (zero) on my first finger...