Issues with auto reset

[MCUdude]

Hi!

I figured out that the provided hex file for the 328p in this repo was a bit dated, so I compiled a new one file that supports autobaud.

I'm currently using a genuine UNO with an ATmega8u2 as the USB to serial converter. I'm having problems with the auto-reset routine. I am able to upload if I hit the reset button at the right time, but auto reset does not work at all. Any reason why this might happen?

It also seems like the microcontroller gets stuck in bootloader mode when I open the serial monitor after a successful upload. the D13 LED is constantly lid, and the sketch isn't running.

[nerdralph]

I've occasionally seen something like that which appeared after I added autobaud, but haven't been able to consistently reproduce it. I think it may be from turning on the USART part way through the first STK_GET_SYNC message that avrdude sends. I just started testing a change that pauses after autobaud before you posted the issue. Expect an updated version within 24hrs. I'll also push a new hex file for the 328p and 168p.

[nerdralph]

The bootloader mode toggle was causing problems with a Uno clone I have because it's auto-reset circuit was resetting the AVR after the CH340G was enumerated by the USB stack.
I decided to remove the booloader mode toggle, and go with a timeout. This means it works more like Optiboot, but I use a busy loop timeout instead of WDT. I just pushed a v3 beta, and compiled for m328p. It's now over 256 bytes though. I'm going to try to pare it back down to 256 for a final v3 release so it will again fit in the minimum bootloader size for the m88 & m168.

[nerdralph]

I've just pushed v3b2 (exactly 256 bytes), after lots of testing with both manual reset and auto-reset. It has been very reliable at 250kbps, and fast. Hex files for m168 and m328 have been pushed. I also plan to test with the m88, which may be able to use the same build as the m168.