Do you have the arduino IDE “programmer” set to “avrisp” when attempting “burn bootloader”?
The avrdude command generated by the burn process should never have “arduino” as the programmer type...
The protocol for the Arduino as ISP was changed from stk500v1 to arduino in Arduino AVR Boards 1.6.22 and newer:
The reason is to allow ATmega32U4 boards to be used as Arduino as ISP:
The unfortunate side effect is that the reset disable capacitor is now more likely to be needed on the other boards.
But ... I checked!
/Applications/Arduino-1.8.7.app/Contents/Java/portable/packages/arduino/tools/avrdude/6.3.0-arduino14/bin/avrdude -C/Applications/Arduino-1.8.7.app/Contents/Java/portable/packages/arduino/tools/avrdude/6.3.0-arduino14/etc/avrdude.conf -v -patmega328p[b] [color=red]-cstk500v1 [/color][/b]-P/dev/cu.usbserial-FTD61T6Q -b19200 -e -Ulock:w:0x3F:m -Uefuse:w:0xFD:m -Uhfuse:w:0xDA:m -Ulfuse:w:0xFF:m
/Applications/Arduino-1.8.5.app/Contents/Java/portable/packages/arduino/tools/avrdude/6.3.0-arduino14/bin/avrdude -C/Applications/Arduino-1.8.5.app/Contents/Java/portable/packages/arduino/tools/avrdude/6.3.0-arduino14/etc/avrdude.conf -v -patmega328p [b]-cstk500v1[/b] -P/dev/cu.usbserial-FTD61T6Q -b19200 -e -Ulock:w:0x3F:m -Uefuse:w:0xFD:m -Uhfuse:w:0xDE:m -Ulfuse:w:0xFF:m
Must be because of other boards I have installed?
This one is closer to "stock":
[tt]/Applications/Arduino-1.8.7-test.app/Contents/Java/portable/packages/arduino/tools/avrdude/6.3.0-arduino14/bin/avrdude -C/Applications/Arduino-1.8.7-test.app/Contents/Java/portable/packages/arduino/tools/avrdude/6.3.0-arduino14/etc/avrdude.conf -v -patmega328p [b]-carduino[/b] -P/dev/cu.usbserial-FTD61T6Q -b19200 -e -Ulock:w:0x3F:m -Uefuse:w:0xFD:m -Uhfuse:w:0xDE:m -Ulfuse:w:0xFF:m
[/tt]
Very mysterious...
Ah. Apparently I have installed version 1.6.207 of the AVR core in most of my versions.
While the board manager thinks that this a "much more recent" version than 1.6.23, is actually apparently some sort of interim build near 1.6.21
Yeah, that was the beta test for the new toolchain released in 1.6.22, but without the programmer update. That doesn't seem like it was an ideal versioning strategy. I don't think there's any advantage to using the 1.6.20x versions over 1.6.23.
Burning bootloader from IDE finally works. Turns out that tantalum SMD cap was not good for the job. I replaced it with through hole 10uf and now it burns! Now back to original problem - will test and report back.
Thanks everyone.
Ok, so here's what's still the problem. Pins for USART0 are still taken over with Serial.begin command, even though USART1 is now default communications device. While my code now works and I have pins 10, 9 , 1 and 0 working as native 16bit PWMs, I still cannot use serial debugging. Maybe some register settings are now needed?
Looking at the datasheet, I guess I should disable transmitter:
Bit 3 – TXENn Transmitter Enable
Writing this bit to one enables the USART Transmitter. The Transmitter will override normal port operation
for the TxDn pin when enabled. The disabling of the Transmitter (writing TXEN to zero) will not become
effective until ongoing and pending transmissions are completed, i.e., when the Transmit Shift Register
and Transmit Buffer Register does not contain data to be transmitted. When disabled, the Transmitter will
no longer override the TxDn port.
Is this correct command to achieve this:
UCSRB = _BV(TXEN0);
If you're using USART 1, used "Serial1.xxx" for your IO (assuming that you don't want to change the Arduino Core.)
You can "cheat" and put a
#define Serial Serial1
At the beginning of your sketch.
The bootloader and the Arduino Core (what your sketch uses) don't use each other's code at all, so changing the bootloader to used USART1 has no effect on how sketches behave.
Thanks! That finally nailed it;) I have now 4 16-bit PWM ports and serial line debugging, all working like a charm 
