Mega1284p Usart receiver issues [SOLVED]

9 posts / 0 new
Last post
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi guys

This took me a little time to hunt down on the internet (and here at Freaks), so I thought I'd post a little synopsis in case others come across the same problem. It may save a few hours of head scratching.

Issue: Atmega1284p uasrt receiver (RX0) causes unpredictable crashes / reboots.
Package in question is 40-PDIP.

Resolution: 10k series resistor in line and 100pf cap to ground.

The information is 'out there' but was not easy to find (or my google-fu was letting me down).

Hope this helps somebody.

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

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

I see the freq=1/twopiRC is 159KHz, suitable for use at 115200bps. Good Job.

Imagecraft compiler user

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

bobgardner wrote:
I see the freq=1/twopiRC is 159KHz, suitable for use at 115200bps. Good Job.

Actually, I calculated 159.15kHz. To those that (don't already) know, this is a very simple low pass filter. It serves to stop the 1284p's receiver circuitry from running amok. Weren't Atmel supposed to fix this?

Thanks Bob ;)

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

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

gregsmithcts wrote:
Hi guys

This took me a little time to hunt down on the internet (and here at Freaks), so I thought I'd post a little synopsis in case others come across the same problem. It may save a few hours of head scratching.

Issue: Atmega1284p uasrt receiver (RX0) causes unpredictable crashes / reboots.
Package in question is 40-PDIP.

Resolution: 10k series resistor in line and 100pf cap to ground.

The information is 'out there' but was not easy to find (or my google-fu was letting me down).

Hope this helps somebody.

Would this apply to the other megas? or this problem Atmega1284p specific?

Also, thank you

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

Quote:
this problem Atmega1284p specific?
It's only the 1284p PDIP that I've noticed it on. But my experience is rather limited. It should be fine on any uart receiver that shows similar symptoms.

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

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

Hm, I have been building a 1284P based product for a while and its serial intensive, no problems noticed here. I just wrote an app on my wire wrapped prototype with its 1284P in DIP. We'll see how long it runs.

Is there any info about what triggers this bug, or exactly what problems it causes?

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

As I noted in my first post, the information regarding this behaviour is well hidden away on the internet. The problems are as previously described.
I would only add, that I was using the receiver in interrupt driven mode. When polling, it might not appear. Also Atmel may have fixed this in later chips.

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

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

Chiming in on this topic, because it took me ages to find information on problems I have been experiencing...

References to the problem:

http://www.seanet.com/~karllunt/1284pmemprob.html

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=96253

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=600128

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=107115

My own experience with it:

I have started last year a 644p-based project which is now quite widespread (500+ units). DIP, 20 MHz, MIDI through an optocoupler + pull-up on PD0 (RX0). A few of the first units had a "random crash on incoming MIDI data" glitch which was immediately solved by using a slower opto / larger pull-up. Board noise was suspect #1 but it could have been a smaller version of the problem highlighted here... It has not surfaced again.

I have two other projects around using a similar setup but a different board layout / different set of peripherals. Running for days in my home-studio without any crash.

None of those devices are working more than a few minutes with 1284p (datecode 1017), unless they are disconnected from the MIDI source. This is not a software bug - the problem occurs even when the code setting up and handling data reception on the UART is disabled!

Carving the code to reproduce the problem, I ended up with the following conditions:
- 20 Mhz (seemed to work on a protoboard at 16 MHz)
- DIP40
- ATMega1284p
- Something generating frequent sharp pulses on PD0
- Address-dependent or maybe call-stack dependent. This is the only way I could explain it. The glitch might never occur if some function call is inlined, but if the very same function call is compiled as an actual call, the problem will occur. Adding an ISR that does nothing for a timer overflow also appeared to cause the problem. Padding the code with nops might trigger it. My bet would be on a specific bit pattern on the value of the program counter.

I'll try the cap + resistor thing in my next design, but the most important point for me is that I can't easily upgrade the existing units around with 1284Ps.

Now, any new, official word from Atmel on this besides "fix your layout"? Anybody had access to chips with newer datecodes? I have ordered a 1284p 3 months ago from Farnell and it was still the 1017 batch.

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

The resistor and cap are not the solution - changing the crystal mode from low power to full swing completely eradicates the problem - permanently.