Help in programming the Atmega1284 with maniacbug-mighty-1284p.

I've been uploading to my 1284P via ICSP due to this problem, even just a 23k sketch failed every time via the bootloader and serial.

I've just re-burnt the bootloader and tried the same sketch 3 times and it failed.

I added the 10k series resistor on RX0 and tried again and it worked!

Tried it 6 times and it uploaded 100%.

Removed the 10k resistor and it failed.

Replaced the resistor and it worked 3 times in a row again.

I'll now try re-burning the fuses with the 0xF7 low bit and report back.

EDIT: Used Nick's Bootloader Programmer (for the first time) to re-burn the bootloader and set the fuses (I changed Low Fuse from 0xFF to 0xF7 in his sketch) and retried the upload with no resistor. It worked! Now I just need a big sketch to verify it really.

The most profound thanks to you guys for working together to track down and find a solution to this problem. Ye, you can upload via ICSP, but when your board is in a device that means you have to take everything off the SPI bus. On the board I just had made I actually included a 4 pin DIP switch so I could separate everything else form the ICSP header for any code updates that needed to be programmed. I also have a serial header available as well.

Right, now it appears that the 644P family is in the sketch to be identified but there is no entry for a bootloader or fuses setup. Does anyone know how we might go about adding 644P support?

Enclosed 127kB large sketch. Not to be run, just for upload tests.
Enjoy!

EDIT: deleted - please use the BLINK sketch below..

pito:
Enclosed 127kB large sketch. Not to be run, just for upload tests.
Enjoy!

Thanks for that, but I can't compile and upload as it needs some libraries; NilTROS, NilAnaolg, NilSerial and SDFat

SDFat I can get, but I can't find the others at all so I'm guessing they are ones of your own?

http://arduino.cc/forum/index.php/topic,144715.0.html
But you may take ANY sketch you have handy - just copy and paste those LARGE

byte PROGMEM atmega2560_v2 [] = {
0x0D, 0x94, 0x89, 0xF1, 0x0D, 0x94,

bla-bla stuff from the sketch I posted in it.. You can easily make 512kB sketch from it if you like :slight_smile:

This BLINK compiles 129,948 bytes. You have to have SdFat lib there.
Not for running, just for compile and 1284p upload test..
Remove your SDCARD when playing with it..
No warranties of any kind. Use at your own risk.. :stuck_out_tongue:

Binary sketch size: 129,948 bytes (of a 130,048 byte maximum)

Blink_129048bytes.zip (107 KB)

I managed to find the libraries to use your sketch.

O...M...G...It works!! 127k Sketch uploaded several times.

Fantastic work.

tack:
Right, now it appears that the 644P family is in the sketch to be identified but there is no entry for a bootloader or fuses setup. Does anyone know how we might go about adding 644P support?

I have a optiboot version working on a 644P Bobuino board. I just used my USBtiny to burn the bootload, but the arduinoISP sketch should work also from the IDE once you have the bootloader saved in the correct folder and make the boards.txt entry.

:020000000504F5
:10FC0000112484B714BE81FFF2D085E08093810077
:10FC100082E08093C00088E18093C10086E08093F9
:10FC2000C20080E18093C4008EE0CBD0209A86E0B1
:10FC300020E33CEF91E0309385002093840096BB55
:10FC4000B09BFECF189AA8958150A9F7CC24DD244B
:10FC500088248394B5E0AB2EA1E19A2EF3E0BF2E69
:10FC6000A4D0813471F4A1D0082FB1D0023811F49E
:10FC700085E005C0013811F484E001C083E08DD037
:10FC800089C0823411F484E103C0853419F485E01D
:10FC9000A6D080C0853579F488D0E82EFF2485D0A1
:10FCA000082F10E0102F00270E291F29000F111F09
:10FCB0008ED068016FC0863521F484E090D080E05A
:10FCC000DECF843609F040C070D06FD0082F6DD0E1
:10FCD00080E0C81680EED80618F4F601B7BEE895A5
:10FCE000C0E0D1E062D089930C17E1F7F0E0CF16C5
:10FCF000F0EEDF0618F0F601B7BEE89568D007B65B
:10FD000000FCFDCFA601A0E0B1E02C9130E01196FF
:10FD10008C91119790E0982F8827822B932B129625
:10FD2000FA010C0187BEE89511244E5F5F4FF2E0A7
:10FD3000A030BF0751F7F601A7BEE89507B600FC53
:10FD4000FDCF97BEE89526C08437B1F42ED02DD0D4
:10FD5000F82E2BD03CD0F601EF2C8F010F5F1F4FF8
:10FD600084911BD0EA94F801C1F70894C11CD11CFE
:10FD7000FA94CF0CD11C0EC0853739F428D08EE10F
:10FD80000CD086E90AD08AE07ACF813511F488E078
:10FD900018D01DD080E101D063CF982F8091C00092
:10FDA00085FFFCCF9093C60008958091C00087FF27
:10FDB000FCCF8091C00084FD01C0A8958091C60051
:10FDC0000895E0E6F0E098E1908380830895EDDF08
:10FDD000803219F088E0F5DFFFCF84E1DECF1F939A
:10FDE000182FE3DF1150E9F7F2DF1F91089580E04B
:08FDF000E8DFEE27FF2709946C
:040000030000FC00FD
:00000001FF

And here is the boards.txt entry for the 644P

##############################################################

bobuino644.name=Bobuino 644P optiboot
bobuino644.upload.protocol=arduino
bobuino644.upload.maximum_size=63488
bobuino644.upload.speed=115200
bobuino644.bootloader.low_fuses=0xff
bobuino644.bootloader.high_fuses=0xdc
bobuino644.bootloader.extended_fuses=0xfd
bobuino644.bootloader.path=optiboot
bobuino644.bootloader.file=optiboot_atmega644p-4-5.hex
bobuino644.bootloader.unlock_bits=0x3F
bobuino644.bootloader.lock_bits=0x0F
bobuino644.build.mcu=atmega644p
bobuino644.build.f_cpu=16000000L
#bobuino644.build.core=arduino:arduino
bobuino644.build.core=standard
bobuino644.build.variant=bobuino

##############################################################

Lefty

oric_dan:
..and there lies the RX0 sensitivity problem.

To clarify a little bit - No, it is not the "RX0 sensitivity" problem. That is an urban myth..

RX0 is perfectly fine.

It is definitely the XTAL1-pin placement problem (crystal oscillator input) - and most notably a not good decision at Atmel not to follow ie. the 328p as far as the crystal oscillator pins layout is concerned..

oric_dan:
lefty, where did you get this file? --> optiboot_atmega644p-4-5.hex

I think here:

http://code.google.com/p/optiboot/downloads/list

from here:

http://code.google.com/p/optiboot/

The only bootloader I can't remember a source site from is the optiboot compiled for the mega1280 chip which I found only after several days of searching. But I finely did locate a copy somewhere and now all my mega1280 boards (both of them LOL) are working well with optiboot.

Lefty

oric_dan:

tack:
I managed to find the libraries to use your sketch.

O...M...G...It works!! 127k Sketch uploaded several times.

Fantastic work.

So, just to be sure, this is using the 0xF7 fuse setting, and no low-pass filter on RX0?

Correct.

With the Low Fuse Byte set at 0xFF, the default with the maniacbug files, a 10k series resistor in RX0 fixed upload.

Changing the Low Fuse Byte to 0xF7 cured the failed upload issue completely, with no series resistor or RC filter required at all.

With original setting the crystal oscillator of the 1284p is set to a low-power mode. The oscillations are weaker and the oscillator's input (XTAL1 pin) is much more prone to be pulled/modulated by an external signal. As the analysis has shown it may even come to a stoppage of the oscillation.

The closest pin to the XTAL1 is the RX0 (uart input). When the data come to this RX0 pin from FTDI or other serial data source, the fast leading/falling edges of the serial data may pass through a parasitic capacitance, call it Cpar (Cpar is the capacitance between the XTAL1 and RX0 pins) to the oscillator's input (XTAL1) which is very sensitive in low power mode. The faster/steeper the edges of the data signal the easier they pass through. Even a small Cpar (a few pF) may let pass the serial data signal to XTAL1 pin and thus influence the crystal oscillator frequency (even shut him down).

When you put a serial resistor into the serial data path, you introduce a low-pass filter (RC), thus the edges of the data signal are more rounded, not so steep (not so fast, not so energetic, with less high frequency content), and they cannot pass via Cpar easily (because the Cpar is small), so the negative effect on the oscillator is smaller. Therefore it helps.

When you set the mode of the crystal oscillator to "Full Swing Oscillator" the operational condition of the oscillator stage changes, the oscillator takes more power (it becomes a harder signal source), its amplitude is much larger (rail to rail swing, saturated), the input of the oscillator (XTAL1) less sensitive, thus the oscillator is much less prone to be influenced by a parasitic feed through of the energetic edges from the serial data to the pin XTAL1.

The actual issue depends on other factors as well - ie.:
. PCB design (how much Cpar you create, do you use GND guard ring around XTAL1 pin??, are the traces leading to the XTAL1 pin short??, etc),
. crystal parameters (ie some crystals are easier to be driven into oscillation, other not..),
. the oscillator design itself (the circuit inside the chip, may vary based on the chip version),
. frequency of the crystal,
. voltage (the lower the voltage, the lower the recommended crystal frequencies),
. temperature (it shifts the crystal oscillator operational conditions),
. decoupling (bad or missing decoupling capacitors mean a lot of mess on the power lines - that mess modulates the crystal oscillator as well, especially in the low power modes or at lower voltages).

That is my current understanding.. :wink:

pito:

8MHz crystal

57k   3.7% error
115k 7.8% error
16MHz crystal
57k   2.1% error
115k 3.7% error



Thus even a small additional error introduced ie. by such frequency pulling by Rx signal edges may disturb the Uart communication easily..

that does sum it up. except its the errors that allows this to work at all. urban myths notwithstanding, the actual problem is arduino designers infatuation with round numbers. taking into account 3% is considered fatal error for pc rs232 its a miracle any of the boards work at 115k. failure is the rule rather than exception at 8mhz. often the poor noobs blame hardware or boot code when in fact slightly different xtl choice would fix everything. its just another reason i prefer using the internal oscillator which allows far more reliable serial than xtls at those frequencies.

The alternate fuse setting was mentioned way back in Issue with Mighty 1284P Optiboot bootloader on STK500 - #8 by westfw - Microcontrollers - Arduino Forum
But did not solve all problems.

http://www.wormfood.net/avrbaudcalc.php

I dunno. Trying to second guess hardware problems, remotely, without pictures, or test equipment, or actual part numbers and datasheets (for the crystals, for instance), or expertise (this is a pretty hard problem, so the amount of test equipment and expertise required could be quite high), is a pretty frustrating experience.

I thought everyone was already using the "full swing driver" fuse :frowning:
Of course, I also thought I had already changed in the the Optiboot repository makefiles, and it isn't changed there either! Sigh.

I thought everyone was already using the "full swing driver" fuse :frowning:

All 5 board selections in the boards.txt file of the maniacbug 1284 library show the
0xFF lower-power oscillator fuse setting. Maybe you might mention this whole issue
to him. I had no luck getting his attention in the past.

Hello everyone!
This is just to let you know that 0xF7 lfuse trick solved the upload problem for my standalone 1284 board. That's right, just 1284, no P.
Thanks!

xenocid:
Hello everyone!
This is just to let you know that 0xF7 lfuse trick solved the upload problem for my standalone 1284 board. That's right, just 1284, no P.
Thanks!

Interesting, did you verify that you actually had a problem with the 1284 non-P chip when
using the 0xFF fuse settings? I don't remember anyone else having a problem with non-P.
I am also interested in the data code on your chip - something like 1216 or 1247, under the
part number on the top surface.

The top surface says ATMEGA 1284 PU 1216. It is definitely a non-P since i had to change the signature in avrdude.conf to have it recognized (0x1e 0x97 0x06 as opposed to 0x1e 0x97 0x05 for Ps). And yes it had problems with uploading anything larger than ~1000B. Both RC filter and 0xF7 lfuse solved this issue.

Thanks, another fact to put in the book on 1284s.