Custom MoteinoMega cannot flash through FTDI [solved]

[JoelW]

I used a MoteinoMega to prototype a product for a client.  All is well with the prototype, moving to production.  Based my schematics on the ones for MoteinoMega, obv.  I already programmed the Optiboot bootloader to the device using Avrisp mkII, that went successfully.  When I press reset button on board, pin 15 LED flashes a few times to indicate it's powered up and looking for serial port data.  Power rails look good, which is also indicated by bootloader program running.

Now when I switch to using LPL's FTDI Adapter, I can't get the board to program using the Arduino IDE.  I get all sorts of variations on the basic:
avrdude: stk500_recv(): not in sync
errors. 

Checked that COM port is correct as shown in Device Manager, played with various baud rates to no avail.

I did have to make some changes to boards.txt in the Arduino directories to get the bootloader to work (sidenote: surprised by that, maybe I have an old version), but I didn't make any changes to the MoteinoMEGA.upload settings.

I'm not sure where to go from here, what the issue could be.  I'm using the standard settings on the FTDI adapter (5V power, 3.3V logic, DTR), and like I said I'm following the same schematics so I've got a 0.1uF capacitor between DTR pin and the RESET line. 

One last thing I'll note is that I've noticed the FTDI Adapter's RX LED does occasionally blink once with each retry attempt.  It surprised me to see RX flash since I'd think the first thing happening is TX activity (as viewed by the Adapter view, transmitting out to the DUT). 

Any ideas?  Really appreciate it!

[Felix]

I guess your bootloader doesn't respond to the IDE?

[JoelW]

Hi Felix,
What do you mean it doesn't respond?  If you mean the Arduino IDE isn't responding to the bootloader's attempt to connect to the Arduino UART, then yes.

I'm using your bootloader though, DualOptiboot_V5.0_atmega1284p_BlinkD15.hex
I kept the LED on pin 15 on our PCB, for debug purposes, and it's indeed flashing and holding on for a second like it's waiting for communications.

Any ideas?

[Felix]

That red RX blink is "normal" with a failure, that's what I tend to see as well when there's a problem and I get that message.
It usually is a connection problem, or a mismatch between what the IDE expects and what the bootloader delivers (in the initial handshake).
It's too hard to guess what's going on, maybe using a logic analyzer can help debug the serial stream between the IDE and the bootloader, but that would be a last resort.
Not sure what else to suggest, seems like you did everything right.

[JoelW]

I noticed that your documentation says that the default for the FTDI programmer is to use RTS, and the picture on the product page shows that.  But upon closer inspection I noticed it was defaulting to the DTR jumper instead.  Did the product change recently?  I'm trying to look for any deltas between what I prototyped and what I made.  I sent my programmer to my client so he could experiment, so I had to buy a new one recently and was hopeful that this might be the diff.

However, I just cut the trace and switched it to use RTS, and it's still not working.  If using RTS is there anything different I need to do, like short that cap?  I'm reading about this online and not seeing anyone mention how those choices affect the schematics.

[JoelW]

I got this working.  Posting here in case anybody else runs into this.

So, there was one diff between my hardware and the standard MoteinoMega that I forgot about (just takes one, right!), which was that in our application we need to run at 3.3V instead of 5V and somewhere I read recommended only 16MHz for 5V applications, so I swapped in a 10MHz oscillator on our board. 

To get this to work properly, I had to change the f_cpu line in boards.txt to match and also scale the bootloader baudrate (from my research online, DualOptiboot came from the Mighty-1284p lineage, which was written for 115200 baudrate).  So scaled 115200 by 10/16 to 72000 baud also in boards.txt.  Arduino warns this is a non-standard baud rate, but happily burns and verifies that all bytes sent correctly.