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

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.