Problem with custom Atmega2560 board, cannot use FT232 for Serial comms

I'm working on a custom-designed board (designed by someone from this forum) with some rather odd results. I wonder if anyone can give some clues.

The processor is an Atmega2560, and it is connected to a USB port via a FT232RLSSOP FTDI chip. The processor is running (or appears to be) at 16 MHz from a nearby crystal.

What I can do ...

  • I can "talk" to the Atmega2560 chip using ICSP interfacing.
  • I've uploaded a bootloader.
  • I can upload a sketch using this bootloader on my Windows XP PC.

What I can't do ...

  • I can't upload sketches using the bootloader (same USB cable) from my Mac, although the same Mac is what I normally use to upload to Unos, Mega 2560 boards, Leonardo etc.
  • If I upload a "communications" sketch like the "ASCIITable" that comes with the IDE, nothing appears in the serial monitor, or occasionally just a line or two.
  • Different baud rates don't help, either I see nothing or just a few characters.
  • Adding a delay in the loop of ASCIITable seems to make things worse, nothing appears at all.

I don't understand how the USB serial interface can work to upload a sketch, using the bootloader, at 115200 baud, but if the sketch itself writes out data at 115200 baud, that data doesn't appear.

All of the chips are SMD devices, and it is difficult or impossible to connect up the logic analyzer to see what signals, if any, are travelling between the main processor and the FT232 chip.

The client for whom the board is being developed, on the other hand, was able to upload the ASCIITable sketch, and have it work perfectly. That appears to rule out egregious errors, like a missing link or solder bridge on the board. Plus, the fact that sketches can be uploaded using the bootloader also appears to rule out major design or implementation errors.

Any suggestions welcome. :slight_smile:

Hi Nick,

What i will say doesn´t help i think, but i have a similar problem.

I have a custom designed board with ATmega 2560 and ATm3ga328P processors.

I have to 7 FTDI breakout boards from sparksfun, https://www.sparkfun.com/products/9716.

The fun part is this..., only 2 of this FTDI boards are able to program the AT328P however all 7 are able to program the AT2560.

I have been figthing with this problem for some time and never understood why this happens.

It seems to be a similar behaviour to what you have.

regards

Well, there's possible mismatch of the UART speeds.
The Uno serial code had to undo some logic that found the "best" set of baudrate divisor and "use double speed" option because while some of the bitrates it was coming up with were "closer" to the desired rate, they were NOT closer to the rate that the 8u2 was actually running (which was always using double-speed?) IIRC, there were a couple of specific rates where the 8u2 and 328 were "off" in separate directions, resulting in a failure to interoperate.

the FT232 has an internal clock (of somewhat questionable accuracy) that may or may not be synced to the USB clock before being used to run the baud rate generator. Perhaps the m2560 bootloader bit rate (57600?) is a "hole" where the FT232 and the AVR code do not match up (or match up only during bootloading?)

Thanks, westfw. I've been thinking along similar lines, and note that the FT232 is not crystal-driven. However the puzzling thing for me is that (some of the time at least) it can upload a whole sketch, but then moments later can't communicate at the same speed (115200) or other speeds (eg. 9600).

Unless, perhaps, the logic used in the bootloader to derive the serial port settings are more accurate? Maybe they hard-code in the exact dividers needed, but the HardwareSerial does an approximation? I'll take a look at that.

The 8U2 used on the Uno and similar is crystal-driven, so that would be more accurate. And the very fact that they chose a crystal and not a resonator would appear to indicate that it was required, for reliability.

The FTDI has
Frequency of Operation: 11.98 Min-12.00 Typ -12.02 Max MHz internal oscillator, which is multiplied to 48 MHz.
Note 1: Equivalent to +/-1667ppm

I've not seen these kinds of issues using crystal-less FTDI modules to download into 328Ps & 1284Ps.
Especially the severe not communicating at all.

It wouldn't be a MAC FTDI driver thing, would it?

http://www.ftdichip.com/FTDrivers.htm

Nick, can you tell us what your fuses are set to? I have a circuit (designed by the same guy) that works perfectly using the exact same chips.

One more simple thing to check, and I realize Nick you really know your stuff so I hesitate to ask, but have you tried to change the end of line conventions? Unix (Mac) and Windows use different EOL conventions. So try making sure you get a CR and a LF after each line? I read your post again and this really feels like a terminal issue on the Mac,

These are my current fuse settings:

Attempting to enter programming mode ...
Entered programming mode OK.
Signature = 0x1E 0x98 0x01 
Processor = ATmega2560
Flash memory size = 262144 bytes.
LFuse = 0xF7 
HFuse = 0xD9 
EFuse = 0xFF 
Lock byte = 0xFF 
Clock calibration = 0xA4

It wouldn't be a MAC FTDI driver thing, would it?

I downloaded the latest FTDI driver yesterday. That made no effect. Besides it is marginal on Windows, and I also upgraded that to the latest FTDI driver.


have you tried to change the end of line conventions?

I have them set to newline right now, but that is really for when you hit the Send button. That doesn't apply to something like the ASCIItable sketch.


I looked at page 231 of the Atmega2560 datasheet. I thought maybe the bootloader used a more accurate clock setting than the HardwareSerial but in both cases they chose (for 115200 baud) UBRR0 = 16, and set the U2X0 bit, giving an error rate of 2.1%.

If one had chosen UBRR0 = 8 (and not the double-speed bit) that would have been a point of difference, but no.


Despite that, I then made up a test using 57600 baud which has an error rate of -0.8%, and it still didn't work (on the Mac, or on Windows).

I then tried 2400 baud which supposedly has a 0% error rate, and on the Mac got this (in total):

37, hex: 25, oct: 45, bin: 100101
&, dec: 38, hex: 26, oct: 4eø

At 2400 baud, on Windows I only got two bytes (both incorrect) returned.

I'm leaning towards thinking there is either something wrong with the FT232 chip, or possibly the FTDI driver, even though I upgraded them.

The chip/driver must auto-detect the baud rate coming from the processor, and they seem not to be doing as good a job as the 8U2 chip.

It could... The ASCII table sketch write line after line of text, so if you had a CR but not a NL I can see it just overwriting the top line over and over, with the last line being blank and the display output possibly being subject to how the terminal app buffers. I usually do CRLF but a NL should at least dump text upward as it wraps around. So that should be good.

The exact same sketch works perfectly on a Mega 2560 board, with the same settings, so I don't think it is that.

Serial.println does this:

size_t Print::println(void)
{
  size_t n = print('\r');
  n += print('\n');
  return n;
}

You can see it sends \r and then \n, regardless of what the serial monitor settings are.

Somebody else had problems:

http://cliffle.com/project/eris/2011/03/23/ftdi-performance/

Linked to an application note:

There's one difference between what works (uploading a sketch) and what doesn't (the ASCIItable program). One involves a lot of incoming data (the sketch) with occasional acknowledgement. The other involves a lot of outgoing data.

Given that the FT232 has a 64-byte buffer, apparently, I can see it might be possible that a large amount of outgoing data would fill the buffer, it then attempts to send the packet to the PC, and meanwhile, loses the other stuff the processor is trying to send to it.

Does that sound feasible?

It appears you may be on the right track. This dump is 64 bytes long.

I don't have the same setup, but I tested my FTDI cable (from SparkFun) to Serial1 on my Mega 2560 and it worked with the ASCIITable sketch with no problems (on Windows). I will try it later from my Mac.

Okay, again I don't have the same setup, but I was able to test my FTDI cable to Serial1 on my Mega2560 on a Mac Powerbook 10.6.8. The ASCIITable sketch did run okay to Serial Monitor (I tested both 9600 and 115200 baud ok). I do have a few more FTDI cables and boards I could test with to see if test may vary any.

There's a utility you can download from ftdichip.com: FT_PROG 2.8.2.0 - EEPROM Programming Utility

http://www.ftdichip.com/Support/Utilities.htm

I got a copy, thinking I could see how the FT232 chip was configured. Well that worked but I couldn't see anything obviously wrong.

Then it occurred to me last night to compare the chip to a working one in a board from another manufacturer. Maybe there is something that is a default that everyone knows to change, like the "divide by 8" bit in the processor.

Hmm, could be. I've never seen anyone ask about that before.
Is it summer there yet? Another snow storm just letting up here, maybe some more snow later tonight too.
http://www.intellicast.com/National/Radar/Current.aspx

Is it summer? We just had a run of about 10 days of over 30C temperature (over 86F). Then at nights it only got down to about 25C (77F). It was hot, damn hot.

[quote author=Nick Gammon link=topic=154906.msg1163901#msg1163901 date=1363728782]
We just had a run of about 10 days of over 30C temperature (over 86F). Then at nights it only got down to about 25C (77F). It was hot, damn hot.
[/quote]Wow. If that keeps up retiring Victorians (and Neighbours' characters) could cease migrating up here! I'm pretty sure that was foundation of our state's economic recovery plan too :astonished: It's officially Autumn, but here it's raining due to ex-tropical cyclone 'Tim' and we have a warning of another potential cyclone forming up north. That's xmas weather...it's all gone a bit weird.

Geoff

The chip/driver must auto-detect the baud rate coming from the processor, and they seem not to be doing as good a job as the 8U2 chip.

How do you mean? Neither the ftdi nor the 8u2's firmware do that, they just impose the baudrate sent over usb by the pc on their uart.

About the theory of overflowing the ftdi's 64 byte buffer. What if you send data only every say 30 msec? (the buffer is flushed over usb after a configurable timeout which is 16msec by default).

How is the ftdi connected? Is there an auto reset line (DTR or RTS) towards the atmega? Are the other flow ctrl signals connected (toggling cts,... flushes the buffer too)