Triggering of watchdog when using SOFT_UART option

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use omake with flag SOFT_UART
2. Flash into uC
3. Attempt to load sketches, small to large

What is the expected output? What do you see instead?
Expect to see successful communicators and uploading.  However, handshake is 
consistent but incorrect.  Or, of one is able to start uploading a sketch - it 
will repeatable fail part way through. 

What version of the product are you using? On what operating system?
Windows 7, optiboot source v6.4 dated Aug 2014.

(I did the above with a port of optiboot to the ATmega64M1 uC and found the 
problem.  I suspect it will also be repeatable using more common uC's, ala the 
ATmega328p - but have not reproduced the issue outside of the 64M1 uC)

Please provide any additional information below.
I have ported optiboot to support the ATmega32/64M1 uC.s  One challenge is 
these uCs do not contain a traditional UART, so I enabled the SOFT_UART option. 

I was not able to get a reliable sync via AVRDUDE even though I was able to 
proof the software UART basic functionality via test edits to the optiboot 
source combined with O'Scope probing.  During this I noted the serial transmit 
line (from the uC to the computer) was at times in the wrong rest state (low 
vs. High). 

Turns out the system reset via the watchdog timer causing this 'disruption'.  
An O'Scope verified the timing matched the selected value to the watchdog timer 
(1 second in the current source).  Increasing the timeout value to 2 seconds 
allowed me to complete a handshake and upload a blank sketch.  However, a 
slightly larger sketch would start to upload and then fail.  Again increasing 
to a  still larger value (8 seconds) allowed more progress, but at this point I 
started looking for other issues.

Proposed Solution?
In the function getch():  With the hardware UART  you do a watchdogReset() upon 
every successful character read. But there is no such call in the software UART 
option.  By adding a watchdogReset(); directly after the #ifdef SOFT_UART 
inside getch(void) I was able to restore the 1 second watchdog timing 
capability and load successfully load sketches via the software UART.  Large to 
small.

I propose that the code be modified to include a call to watchdogreset() inside 
the SOFT_UART option of getch().  Even though this will not cause a timeout in 
the case of repeated framing errors, there are many other traps that will cause 
exiting optiboot and begin application execution.

Original issue reported on code.google.com by mv.Vikin...@gmail.com on 26 Jan 2015 at 2:06

[GoogleCodeExporter]

Thanks for the bug report.  I think it's been a long time since the code was 
tested with the soft uart option, so it's not too surprising that it doesn't 
work right.
Your suggestion sounds fine, and I'll see about getting it into the source with 
the next set of edits.

Original comment by wes...@gmail.com on 4 Feb 2015 at 9:51

[GoogleCodeExporter]

Happy to help :-)

Original comment by mv.Vikin...@gmail.com on 5 Feb 2015 at 11:28