ATMEGA32U4 wdt immune delay in Serial.print().

Projects Programming
1

I used a cheap Chinese "pro micro" for simple timer-base automation.

I do not need the USB serial during normal operation, but for the present, my code is outputting some informational messages every minute using several Serial.print() calls.

I happened to notice, via the blinkenlights, that my code was hanging periodically for over 10 seconds. I determined that this hang was when I was issuing the Serial.print() calls - a total of around 47 Serial.print()s was taking around 14 seconds to complete. Those Serial.print() calls normally take around 3 to 4 milliseconds. The delay happens when the windows computer the pro micro is connected to was shut down (but not turned off so still providing power to the pro micro).

I tried wrapping an "if ( Serial )" around the Serial.print() calls, but the problem still happens. If I power the board via raw, with nothing connected to the USB, as I will eventually be doing, I don't get the problem.

Another observation is that when I get the hang, the one second wdt does not reset the board. Yes, I have tested, by deliberately putting my code into a loop, that the wdt does normally work, but for some reason it does not fire during these hangs or delays in Serial.print(), and I'm not doing a wdt_reset() anywhere near there.

I found some discussion about problems with USB after waking up from sleep on ATMEGA32U4 based boards, but I'm not going to sleep - at least, not deliberately!

Since I know how to avoid the problem, and in fact it probably won't occur anyway as USB won't be connected, this is no big deal. However, I'm curious to find out why it hangs in the circumstances that it does, and why the wdt fails to reset.

Thanks for your attention.

2

After some more digging I found references to Serial.availableForWrite(), which returns "the number of bytes (characters) available for writing in the serial buffer without blocking the write operation". I thought perhaps that could be used instead of, or in addition to "if ( Serial )", but it appears that availableForWrite() is not implemented for Leonardo/pro micro USB serial. At least it is not available unless I mess with the Arduino code like this:

Edit: I noticed availableForWrite() seems to have made it into the 1.6.6 code.

However, that was enough to point me to here, where I think the Serial.print() data ends up in
hardware/arduino/avr/cores/arduino/USBCore.cpp:

//	Blocking Send of data to an endpoint
int USB_Send(u8 ep, const void* d, int len)
{
	if (!_usbConfiguration)
		return -1;

	int r = len;
	const u8* data = (const u8*)d;
	u8 timeout = 250;		// 250ms timeout on send? TODO
	while (len)
	{
		u8 n = USB_SendSpace(ep);
		if (n == 0)
		{
			if (!(--timeout))


				return -1;
			delay(1);
			continue;
		}
      . . .

So, it seems that if there is no buffer space, and the data is not going anywhere, then it will hang there for 250mS. I'm not sure exactly how many calls to USB_send will result from my Serial.print()s, but that probably explains the delay.

From some of the comments in CDC.cpp, it appears that the intention is to behave "just like a UART" and throw data away if something strange has happened, but perhaps they have not covered all bases.

As for why the wdt does not trigger, I'm not sure. I couldn't follow the entire path from Serial.print() to USB_send(), so perhaps there is something along the way that resets or disables the wdt.