Mega2560 Serial Issue, Potenial Fuse Traces?

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello AVR community, I am involved with a custom PCB implementation of a mega2560 and I cannot seem to figure out my situation. I am unable to connect to the mcu over USB serial(FT232RL) with a baud rate any higher than 57600, as everything received on the serial port is just scrambled. So my guess would be some sort of clock calibration? I thought I had the correct fuses for my setup, but maybe someone could verify or lead me in the right direction to figure things out.

 

The board has a 16Mhz miniature ceramic crystal on XTAL1 & 2 so the high LOW fuse is set at 0xFF.

The low HIGH fuse for the boot loader is 0xD8.

The extended BOD fuse is at 0xFD.

 

What can I try to tackle this problem? Thanks, Chris

Last Edited: Tue. Sep 19, 2017 - 02:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Those fuse values sound a bit suspicious. Engbedded says:

 

 

Can you really mean you have switched off JTAGEN and SPIEN ?!??

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh my! I wrote the order down wrong in my original post.. That never helps anything. You'd be correct, I did not jack up the SPI lines! Apologies! surprise

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looks more sensible...

 

But note from here:

 

http://wormfood.net/avrbaudcalc.php

 

So if the baud rates over 57600 you are trying to use are specifically 115,200 and 230,400 then don't be too surprised if they are not OK as the first has a -3.5% error and the other is a definite no-no with a +8% error. However, 76,800 should be OK. If you want to use 115,200 try it with U2X as that switches the error from -3.5% to +2.1% which is just about usable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PS if you do want to use "high rates" (and not the 0.25/0.5/1 M ones) then why choose 16MHz? Why not a "baud rate friendly" 14.7456MHz or 18.432 MHz ??

 

Is this about Arduino"Mega" compatibility perhaps?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for that information. The only compatibility I was looking for was appropriate serial interaction within a serial terminal monitor at standard baud rates, I didnt realize that 16MHz isnt baud friendly. 57600 will work for my application, but I was just confused as to why I could not communicate at anything higher.

Last Edited: Thu. Sep 21, 2017 - 01:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sktbrd2 wrote:
a 16Mhz miniature ceramic crystal

You mean a ceramic resonator?

 

Ceramic resonators can be used as the source of the clock signal for digital circuits such as microprocessors where the frequency accuracy is not critical.[3] Quartz has a 0.001% frequency tolerance, while PZT has a 0.5% tolerance.

 

https://en.wikipedia.org/wiki/Ce...

 

Last Edited: Tue. Sep 19, 2017 - 03:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I thought our engineer had a crystal installed with two 18pf caps on each side. Here is the component on the board: https://www.digikey.com/product-...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That is a "crystal", and yes, as you stated, it uses two external caps as well.

 

The term "ceramic" generally applies to a ceramic resonator, which a little bit different than a "crystal".

Hence the concern, as the frequency setting component of the system is important when discussion / debugging baud rate issues.

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Initially, in the opening post, sktbrd2 wrote:
a 16Mhz miniature ceramic (sic) crystal

So I wrote:
You mean a ceramic resonator?

Then sktbrd2 wrote:
I thought our engineer had a crystal installed with two 18pf caps on each side. Here is the component on the board: https://www.digikey.com/product-...

Yes; that's a crystal - a quartz crystal, to be precise - so the "ceramic" in the OP was spurious.

 

EDIT

 

Aha - I guess "ceramic" came from:

 

In the ABM3 datasheet, Abracom wrote:
• Ceramic package hermetically glass sealed assures high precision and reliability

 

http://www.abracon.com/Resonator...

Last Edited: Tue. Sep 19, 2017 - 04:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I appreciate the clarity of your posts everyone. Good distinction between the clock source types, I realize that calling it ceramic wasnt actually proper, just misleading from the datasheet aha. So then if my fuses are set for the correct external clock type, is there anything else I should consider besides setting the double speed operation bit(U2X0 = 1) in the UCSR0A? Such as hardware design?

While I was troubleshooting, I considered resistors and their reasoning for being in series on the TX/RX lines. On the arduino mega2560 R3 schematic, there are 1k's between the mcu and the mega16U2 for usb. Should I have similar resistors between my ftdi chip and mcu as well?

Last Edited: Thu. Sep 21, 2017 - 02:25 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You could place the serial resistors in your FTDI to uC USART lines to help keep the system safe.

 

On the Arduino one is connecting two I/O pins on one micro to two I/O pins on another micro.

If there was either a code error, or a glitch in the system, it is possible that one micro could be trying to drive the line high while the other micro is trying to drive the line low.

This is a bus contention.  The (digital) bus is suppose to be either high or low, and one can't have two drivers both trying to pull it in opposite directions.

Doing so may well fry either the I/O pins, or the micro as a whole.

 

With the FTDI chip, the I/O pins are dedicated, (IIRC), and one can't flip their function back and forth.

BUT, they are still connected to a micro, so the FTDI TxData line could still be trying to drive that signal one way while the micro, in an error state, misconfigures the  RxData (input) pin as an output and tries to drive the signal to the opposite state.

 

(Hence you really only need one resistor, not two, with the FTDI chip...  It's RxData pin can't be converted into an output, IIRC)

 

That's the concept, anyway.

 

JC