Set TX, RX to LOW before sleeping, re-enable uart after waking up

Question

I have an ATmega1284p and I need to have the TXD0 (i.e. pin 9) set to LOW, before going to sleep. After waking up, I want to restore UART0 communication to work as expected. Here is my code:

Serial.begin(38400,SERIAL_8N1);

*do Stuff*

Serial.end();
//pinMode(9,OUTPUT);
//digitalWrite(9,LOW);      
//UCSR0B &= ~bit (RXEN0);  // disable receiver
//UCSR0B &= ~bit (TXEN0);  // disable transmitter
cli();           
set_sleep_mode (SLEEP_MODE_PWR_DOWN); 
sleep_enable();
// turn off brown-out enable in software
//MCUCR = bit (BODS) | bit (BODSE);  // turn on brown-out enable select
//MCUCR = bit (BODS);        // this must be done within 4 clock cycles of above
sleep_bod_disable();  //disable brown-out detection
sei();             // guarantees next instruction executed
sleep_cpu ();              // sleep within 3 clock cycles of above
sleep_disable();

//  UCSR0B |= bit (RXEN0);  // enable receiver
//  UCSR0B |= bit (TXEN0);  // enable transmitter  
//pinMode(9,OUTPUT);
//digitalWrite(9,HIGH);
//delay(100);
//pinMode(9,INPUT_PULLUP);
Serial.begin(38400,SERIAL_8N1);
delay(1000);
Serial.println("- Good Morning");

*do Stuff*

You can see in comments all the different things I tried:

• Using Serial.end() and then, after waking up, Serial.begin()
• Using the UCSR0B register
• Using digitalWrite to set the pin to LOW and then, after waking up, either setting it to high, or setting it as input

All of the above combinations have the common problem that the cpu hangs after waking up, and the Serial is never restarted to print good morning message, neither does the program continue to execute further down.

Answer 1

After trying many different alternatives, it turns out that my mistake was that, foolishly, I had included Serial printing inside my ISR routines, which where accessed when my interrupt fired, in order to wake my uP. As a result, Serial.print was called, with Serial being closed (before issuing the Serial.begin command to restart it), thus breaking my uP.

Extra: Just wanted to comment about using Serial.print inside ISRs. Although it can lead to unexpected problems like this one, or timing issues (ISR would take too long to execute) and is definitely a bad practice, it can sometimes be useful for debug purposes during development to print some kind of message there.

Printing a message takes long, and the ISR will return before the message is completely transmitted, with the potential to cause a lot of headache. Also, interrupts are disabled inside ISRs, so delay() is not working to do some kind of flow control. The best way to print messages in ISRs that I have come across so far, is by using Serial.flush() before exiting the ISR, making sure the message is completely transmitted.