Weird serial behavior on atmega2560

Question

EDIT This seems to be something to do with the oscillators. Switching to the internal oscillator and writing straight avr-c allows me to run a basic blink program. Writing the same basic blink in arduino and flashing with the IDE (through serial or usbasp) results in a non functional program. I'd like to be able to use the oscillator because it doesn't look like I can get everything done in time at 8MHZ

I have an arduino mega 2560 which a few weeks ago was working fine. Now, I'm trying to output some data from it, and 've broken it down to a very, very basic proof of concept:

void setup() {
// put your setup code here, to run once:
 Serial.begin(9600);
}
void loop() {
 // put your main code here, to run repeatedly:
 Serial.println("hello");
}

This prints:

hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

indefinitely on the screen. If I change the baud to 115200, I get the "hello" and the newline, and slowly start getting garbage afterwards. If I switch to 234500, I get a few prints, and then nothing.

Adding a delay after the print does not change the frequency of the serial prints:

void loop() {
// put your main code here, to run repeatedly:
 Serial.println("hello");
 delay(100000);
}

They still come in immediately.

I have a feeling this has something to do with timing of an interrupt, but I'm not setting anything up. I plan to reflash and fix the fuses, but my usbASP cable is broken right now. Any other input on what might be going on here?

Edit: This occurs on two different boards. I originally had some i2c devices (mag/gryo/barometer) on board, but those have since been removed. I have tried two different usb cables in two different USB ports. This might be on the host side?

Edit: Both the TX and Rx lights are solid this whole time. Almost as if there's a loopback. My other laptop won't even boot right now. I'm concerned a surge from a storm last night might have taken out both of these machines

More testing: Looking at the output on a scope, the board is actually only outputting an "h" character. If I do:

Serial.println('U');
delay(1000);

I get a square wave, so the delay doesn't run at all. If I do: Serial.println('U'); Serial.println('U'); //or any other character delay(1000);

I get a U character over the scope, and then an empty serial frame. The delay still doesn't run, but it looks like the second println is exiting.

Even burning a new bootloader fails on these boards

• PMF: This does look like some kind of hardware problem. I have seen Uart chips causing strange output and act as if having a loopback, but only on real Uarts, not on USB devices.
• JRobert: Was either of the Atmega boards connected to anything during the surge? Was the host computer plugged in to power? It does sound like the common element is your computer's USB. Can you try using a different physical USB port on the laptop? A different laptop?
• Brydon Gibson: I've brushed both boards to eliminate shorts. I'd accept hardware failure but two previously working boards on the same day?
• Brydon Gibson: @jrobert boards were not powered, laptop was charging. My other laptop (also charging) will not boot today, which contributes to my suspicion
• timemage: It would help to print something distinct in setup() to know whether or not the boards are resetting.

Answer 1

Answering my own question - a bit of a walk of shame here.

I had disabled the internal TIMER0_OVF_vect in the arduino core code, so that I could write my own (for another project). I wrapped in in an #if 0 so I could go and bring it back when I needed it.

Today, I learned that the atmega interrupts aren't filled with an IRET by default, but instead hit the reset vector, resetting the board. Anything I compiled on this library would reset whenever TIMER0 overflowed, because my ifdefs didn't cover the TIMSK setting in the arduino core either

The "Serial.println isn't exiting" was actually "the board is resetting before it can complete" and explains why faster bauds could print more data.

Not much smarter than hairless apes, sometimes.