ATmega1284 silicon errors?[solved fast crystal needs CKSEL3]

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

Hi,

I'm working on a project where I use m16, m324 and m644. Our customer bought a lot (ca 5000) atmega1284(not P) and of course wants us to use them.

The issue is that code that runs fine on the other processors crash (freeze or go extremely slow) on the m1284. Everything (SPI, timers etc.) works fine until we send data to the UART. The problems occur even if the UART is disabled and the RX0 pin tristated.
The current design has been produced in tens of thousands without any problem on m644.

I and my colleagues have been scrathing our heads for days now and are starting wonder if there is a silicon error. Or is the m1284 just more sensitive to something not mentioned in the datasheets?
We'll meet an Atmel sales representative tomorrow, but I'm thankful for any hint or help.

Best regards,
Andreas Wileur

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

Double and triple check your AVR fuse settings!

Are you certain you are using the correct AVR 1284 header file? If you are using assembly langauge the register address assignments for various AVR registers may have changed to the other side of the magic 0x3F address boundary, making your in/out vs. lds/sts instruction usage wrong and creating major software bugs.

If you are using an external crystal:
The RxD0 pin is right next to the XTAL1 pin. Have you tried disabling the USART and grounding the RxD0 line (for testing only)?
Are you using the Full Swing Crystal Oscillator setting?

Atmel AVR042: AVR Hardware Design Considerations
http://www.atmel.com/Images/doc2...

AVR186: Best practices for the PCB layout of Oscillators
http://www.atmel.com/Images/doc8...

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

If you are using the delightful Atmel Toolchain compiler instead of WinAVR, the header files have incorrectly spelled USART IRQ vectors.

Rebuild your project, and read the Build output.
Any message about mis-spelled vectors is really an ERROR not Warning!

AFIK, the mega1284 should do everything that a mega1284P can do. Except with a different chip Signature and poorer sleep currents.

David.

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

Quote:
Everything (SPI, timers etc.) works fine until we send data to the UART. The problems occur even if the UART is disabled and the RX0 pin tristated.
I'd expect the Rx pin being tristated in normal UART operation, too, so that does not really represent a change hardware-wise...

But if you double, triple checked that the UART is disabled and the problem reproducibly occurs at, and only at, level change at the Rx pin, then it would indicate hardware problem primarily. I would first write a trivial test program, maybe just echoing back data on the UART incremented or xored by a constant, without anything else, and test it if it exhibits the same problem. I would also try a trivial dummy loop to check if it still persists. If so, I would then disconnect any driving circuitry (MAX232, hopefully); pull the pin up gently [I mean, electrically], and then after starting the program pull it down to see whether the problem occurs repeatably. I would then proceed according to the outcome of these trivial tests.

I know it's laborious, but I always strive to err on the safe side. "Working" does not mean error-free, it only means that the existing errors did not demonstrate themselves visibly so far. What if your design is marginal in some respect, and the particular chip introduced a miniscule change which flipped it over to the wrong side?

I also wonder how exactly would an Atmel *sales* representative help with a problem which is apparently of technical nature, but maybe I just underestimate their capabilities... :-)

JW

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

Could it be related to this issue? ATmega1284P memory problem/fix

Quote:
The corruption can be triggered by injecting sharp-edged pulses onto port line RX0

Stan

Edit: Related thread atmega1284p UART Rx glitch

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

Thank you for quick answers, I have never been disappointed in this forum!

sbennett wrote:
Could it be related to this issue? ATmega1284P memory problem/fix

Quote:
The corruption can be triggered by injecting sharp-edged pulses onto port line RX0

Stan

Edit: Related thread atmega1284p UART Rx glitch

I read this and was very encouraged, first time I've seen anyone else experience the same problem.

Mike B wrote:
Double and triple check your AVR fuse settings!

Mike B wrote:
Are you using the Full Swing Crystal Oscillator setting?

Been there before so of course we checked the fuses over and over. Problem was that on the old m16 we started out with there was a separate CKOPT bit for fullswing, but I've never seen it on m644/m1284 so I assumed it wasn't needed anymore. The thousands boards in production have worked fine without.

Anyhow, looking in the datasheet showed that the function of the fuse bits have changed slightly and clearing CKSEL3 (setting fullswing) solved the problem!

AVR Studio 4, which we use for initial setup, has the settings named in a slightly confusing way. The obvious option for using a crystal is "Ext. Crystal Osc." but the correct one is "Full Swing Oscillator".

Well, thank you very much and hope this can help someone else!

Best regards,
Andreas Wileur

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

Glad you found the culprit.

JW

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

wek wrote:
I also wonder how exactly would an Atmel *sales* representative help with a problem which is apparently of technical nature, but maybe I just underestimate their capabilities... :-)

He didn't know very much... He quickly gave me the email to their technical support:)

Andreas