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.

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!

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.

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?

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!

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.

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

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.

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.