Mega1284p Usart receiver issues [SOLVED]

Log in or register to post comments
Go To Last Post
16 posts / 0 new
Author
Message
gregsmithcts
gregsmithcts's picture
Level: Raving Lunatic
Joined: Thu. Nov 4, 2010
Posts: 2098 View posts
Location: Bristol, UK
#1
Posted by gregsmithcts: Sun. May 22, 2011 - 10:25 AM
  • 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!

Tags:

AVR Microcontrollers, megaAVR and tinyAVR, ATmega128, ATmega1284
Top
bobgardner
bobgardner's picture
Level: 10k+ Postman
Joined: Wed. Sep 4, 2002
Posts: 26669 View posts
Location: Orlando Florida
Posted by bobgardner: Sun. May 22, 2011 - 07:09 PM
  • 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

Top
gregsmithcts
gregsmithcts's picture
Level: Raving Lunatic
Joined: Thu. Nov 4, 2010
Posts: 2098 View posts
Location: Bristol, UK
Posted by gregsmithcts: Sun. May 22, 2011 - 09:20 PM
  • 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!

Top
MarioRivas
MarioRivas's picture
Level: Hangaround
Joined: Wed. Dec 29, 2010
Posts: 475 View posts
Posted by MarioRivas: Sun. May 22, 2011 - 09:22 PM
  • 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

Top
gregsmithcts
gregsmithcts's picture
Level: Raving Lunatic
Joined: Thu. Nov 4, 2010
Posts: 2098 View posts
Location: Bristol, UK
Posted by gregsmithcts: Sun. May 22, 2011 - 09:25 PM
  • 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!

Top
skyjumper
skyjumper's picture
Level: Hangaround
Joined: Tue. Feb 15, 2011
Posts: 116 View posts
Location: Smithfield, RI
Posted by skyjumper: Tue. May 24, 2011 - 03:12 AM
  • 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?

Top
gregsmithcts
gregsmithcts's picture
Level: Raving Lunatic
Joined: Thu. Nov 4, 2010
Posts: 2098 View posts
Location: Bristol, UK
Posted by gregsmithcts: Tue. May 24, 2011 - 05:58 AM
  • 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!

Top
pichenettes
pichenettes's picture
Level: Rookie
Joined: Sat. Jul 11, 2009
Posts: 48 View posts
Location: Paris
Posted by pichenettes: Sat. Jul 23, 2011 - 01:38 AM
  • 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/...

https://www.avrfreaks.net/index.p...

https://www.avrfreaks.net/index.p...

https://www.avrfreaks.net/index.p...

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.

Top
scargill
scargill's picture
Level: New Member
Joined: Sat. Jul 7, 2012
Posts: 12 View posts
Location: Spain
Posted by scargill: Sun. Apr 27, 2014 - 07:05 PM
  • 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.

Top
DominicTW
DominicTW's picture
Level: New Member
Joined: Sat. Feb 14, 2015
Posts: 5 View posts
Posted by DominicTW: Sat. Feb 14, 2015 - 02:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, sorry for re-opening an old thread, particularly as this is my first post on AVR Freaks.

I'm using a raspberry pi to program an Atmega1284p 40-dip on a breadboard via the GPIO powered by the Pi's 3.3v rail and I seem to have run into this problem.

I can load sketches on to the  Atmega1284p without a problem however whenever I try to communicate with the Atmega1284p over serial it resets as soon as it receives data from the Raspberry PI, from the OP's post I'm pretty sure that this is my  problem, however I'm having problems understanding how to apply either of these solutions. 

Could you clarify things for me?

I've tried the first solution mentioned (10k series resistor in line and 100pf cap to ground) but that doesn't seem to work could this be to do with me running the atmega at 3.3v?

I'm not sure what is meant by changing the crystal mode from low power to full swing

Thank you 

Dom

Top
Kartman
Kartman's picture
Level: 10k+ Postman
Joined: Thu. Dec 30, 2004
Posts: 20239 View posts
Location: Melbourne,Australia
Posted by Kartman: Sat. Feb 14, 2015 - 11:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you have 100nF bypass capacitors fitted?
Do you have a crystal connected to the mega1284? How did you set the fuses?

Top
DominicTW
DominicTW's picture
Level: New Member
Joined: Sat. Feb 14, 2015
Posts: 5 View posts
Posted by DominicTW: Sun. Feb 15, 2015 - 08:23 PM (Reply to #11)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey Kartman, thanks for the reply. I'm a rather new to the whole avr thing so I'm not really up on the terminology, if by set fuses you mean burning a boot loader I did it through the IDE, I followed a guide I found here https://maniacbug.wordpress.com/... and http://blog.stevemarple.co.uk/20... and this https://projects.drogon.net/rasp... hmm do you think it's using the internal oscillator?  Yes I think I've got the cap in the  right place.

Last Edited: Sun. Feb 15, 2015 - 08:24 PM
Top
DominicTW
DominicTW's picture
Level: New Member
Joined: Sat. Feb 14, 2015
Posts: 5 View posts
Posted by DominicTW: Sun. Feb 15, 2015 - 09:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The odd thing is that the raspberry pi can receive data from the atmega perfectly if it was using the internal oscillator wouldn't the timing be so off that the data would be garbled? 

Top
awneil
awneil's picture
Level: 10k+ Postman
Joined: Fri. Jul 1, 2005
Posts: 13632 View posts
Location: Basingstoke, Hampshire, UK
Posted by awneil: Sun. Feb 15, 2015 - 09:50 PM (Reply to #13)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DominicTW wrote:
if it was using the internal oscillator wouldn't the timing be so off that the data would be garbled?

Not necessarily.

 

When we say that a type of oscillator is "inaccurate", that does not mean any one specific example of that type of oscillator will necessarily have a large error - just that the range of possible errors over the entire population is large.

 

Also, for asynchronous comms, it depends upon the combined errors in the clocks of both devices.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillator: https://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Top
DominicTW
DominicTW's picture
Level: New Member
Joined: Sat. Feb 14, 2015
Posts: 5 View posts
Posted by DominicTW: Mon. Feb 16, 2015 - 11:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Awneil 

I'm not sure but this would seem to check out?

 

avrdude -P gpio -c gpio -p atmega1284p

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9705

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

 

Top
DominicTW
DominicTW's picture
Level: New Member
Joined: Sat. Feb 14, 2015
Posts: 5 View posts
Posted by DominicTW: Tue. Feb 17, 2015 - 12:03 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Verbose output 

avrdude -P gpio -b 115200 -c gpio -p m1284p -v

avrdude: Version 5.10, compiled on Jun 18 2012 at 12:38:29
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "/etc/avrdude.conf"
         User configuration file is "/home/dominic/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : gpio
         Using Programmer              : gpio
         Overriding Baud Rate          : 115200
         AVR Part                      : ATMEGA1284P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PA0
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    10   128    0 no       4096    8      0  9000  9000 0xff 0xff
           flash         65    10   256    0 yes    131072  256    512  4500  4500 0xff 0xff
           lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00

         Programmer Type : GPIO
         Description     : Use sysfs interface to bitbang GPIO lines

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9705
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DE
avrdude: safemode: efuse reads as FD

avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DE
avrdude: safemode: efuse reads as FD
avrdude: safemode: Fuses OK

avrdude done.  Thank you.

 

 

I found this thread http://forum.arduino.cc/index.ph... on the Arduino forum 

 

 

How have you burnt the bootloader? Nick Gammons sketch, through IDE with Arduino as ISP, or manually using the Arduino as an ISP and command line avrdude?

I'm suspecting you have burnt the bootloader manually, rather than through IDE or Nick's sketch, and not explicitly programmed the fuses.

Have you installed the 1284 cores?

Your fuses don't look right at all.

I use

Lfuse 0xf7
Hfuse 0xd6
Efuse 0xfd

The standard Mighty1284 boards.txt is slightly different but I changed these for a reason:-

Lfuse 0xf7 for full swing oscillator - solves a problem that you can get with serial uploads due rxt/tx coupling with adjacent crystal pin. Full Swing gives a 'stronger' oscillator signal. Mainly encountered on breadboard builds and can be helped by pcb with proper crystal surrounding ground plane for isolation.

Hfuse 0xd6 to preserve EEPROM through Chip Erase. Needed if you program via ICSP, use Eeprom and don't want saved Eeprom data lost every time you load a new versiom of your sketch. I don't think it's required if only programming via serial and boot loadloader OR you don't use the Eeprom.

Hope this helps.

 

Last Edited: Tue. Feb 17, 2015 - 12:17 AM
Top