ATmega2560 and FT230XS on Custom Board, Suspicious Symptoms point to Clock?

Development Tools Uploading
1

Hello world,

This might belong in the electronics forum, but my fundamental issue is not being able to upload a sketch via USB.

The schematic for the board in question is attached, simplified to show only the USB (and ICSP) related connectivity. It's what should be a straightforward implementation of the ATmega2560 using the FT230XS for the USB bridge.

I can upload the stk500boot_v2_mega2560.hex bootloader with an AVR-ISP-MK2 over the ICSP header and it works just fine. The output after writing and the subsequent read/check is:

avrdude: verifying ...
avrdude: 150208 bytes of flash verified

avrdude: safemode: Fuses OK (E:FF, H:99, L:62)

avrdude done.  Thank you.

So that seems good.

Now looking at the USB-UART side of things, I can short the Tx and Rx UART pins for hardware loopback, and this works as well. Characters transmitted from puTTY echo back, and my little Rx and Tx LEDs light up. Good.

So now I looked more carefully at the connections between the FT230XS and the ATmega. There were a few issues that I've identified and resolved over the past couple weeks. These were:

  • Pin 4 (ID) on the USB micro-B connector was tied to ground instead of being unconnected. Resolved.

  • I didn't have 1K resistors on the Rx/Tx UART lines to the ATmega. Resolved.

  • The ATmega RESET's filtering cap to ground was going through an extra resistor. Silly mistake that should not have mattered, but resolved.

  • Here's a big one: I forgot to run the RTS output on the FT230X to the ATmega RESET via a .1uF cap. I thought for sure this would be the ultimate fix, but now this is resolved and still no luck.

But still no. If I attempt a sketch upload I get the standard "avrdude stk500v2_receivemessage() timeout".

The attached PDF is representative of the current state of the circuit.

I've checked that the ATmega's RESET pin is seeing the spike to GND when I try to upload a sketch, using an O'scope. I've also confirmed that there's activity on the ATmega's RX pin when the sketch upload is attempted. But again, hardware loopback works, so that seems solid to me.

Okay, with the above as primer, the plot will thicken:

I can upload a sketch using the ISP by clicking Sketch > Upload Using Programmer, and this works with a simple blinky test on pin 13, BUT, the blinking happens at least an order of magnitude too slow! With a 50ms delay between LED ON and LED OFF, the LED cycles just a bit faster than once per second.

So, it seems like perhaps the clock fuses are somehow not being set correctly in the bootloader, which would explain why I can upload via an ISP but UART communication between the ATmega and the FT230XS fails.

But I'm using the standard bootloader hex file so I don't see how that can be. The resonator I'm using is indeed 16MHz and there isn't a whole lot of room for messing things up with that part of the circuit, although I notice that crystals seem to be more common. My scope probes can't pick up the 16MHz clock signal so I can't do a sanity check with that without investing in a better probe.

I'm not one to post on a forum unless truly at wit's end. Any ideas from the community?

~Justine

ATMega2560+FT230XS_Minimal.pdf (53.5 KB)

2

avrdude: safemode: Fuses OK (E:FF, H:99, L:62

You forgot to set the Fuses.

avrdude: Device signature = 0x1e9801 (probably m2560)
avrdude: safemode: hfuse reads as D8
avrdude: safemode: efuse reads as FD

avrdude: safemode: hfuse reads as D8
avrdude: safemode: efuse reads as FD
avrdude: safemode: Fuses OK (E:FD, H:D8, L:FF)

avrdude done. Thank you.

3

jhaupt:
So, it seems like perhaps the clock fuses are somehow not being set correctly in the bootloader, which would explain why I can upload via an ISP but UART communication between the ATmega and the FT230XS fails.

But I'm using the standard bootloader hex file so I don't see how that can be.

The fuses are not set by the bootloader file itself. In the Arduino IDE, when you do a Tools > Burn Bootloader, it actually does two things:

  • Set fuses according to the boards.txt entry for the current selection from the Tools > Board menu.
  • Upload the bootloader .hex file.

So if you uploaded the bootloader .hex file via the Arduino IDE's Tools > Burn Bootloader, then the fuses should indeed have been set (what they were set to depends on the board you had selected, and possibly even the settings of custom Tools menu items related to that board). However, if you just used avrdude from the command line to upload the bootloader then you skipped setting the fuses.

4

WOW, thank you. That was a gaping hole in my understanding. I was indeed using avrdude directly.

5

I'm glad if I was able to be helpful! It is a little confusing, especially for people who are only going to be uploading via the programmer and so have no need for the bootloader. But a separate Tools > Set Fuses would probably cause an even greater amount of confusion.

6

I agree that the way the IDE does it is sensible. If I'm going to blame anything (besides myself), it's what I perceive to be fragmented documentation for the overlap between avrdude and the Arduino IDE.

But thanks again, this was really a big breakthrough.

7

I agree that it would make sense to completely document the behavior of Tools > Burn Bootloader. That's an advanced operation anyway so it's reasonable for the documentation to be more advanced too.