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

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.

I just went though this exercise, thought I would share

Had a 1284 non P sitting around, wanted to use it for tv out library

downloaded mighty1284, extracted it to my sketchbook folder under a folder named hardware (have to add hardware folder yourself if you have not already)

changed lfuse to 0xF7 in the given boards.txt under the 16Mhz optiboot option

edited avrdude.conf to reflect the different device signature from 0x1e 0x97 0x05 to 0x1e 0x97 0x06

hooked up a 328p home made arduino with ArduinoISP sketch loaded, choose serial port, choose 1284p 16Mhz optiboot entry, burned bootloader. This took its sweet time but did complete.

Afterwards uploading with the bootloader gave an error that the chip was ID-ing as 0x1e 0x97 0x05 and 0x1e 0x97 0x06 was expected. Edited avrdude.conf back to 0x1e 0x97 0x05

seems to work fine, uploaded tv out's NTSC demo and now running a TV display at 240x192

Yep, I burned 1284 non-P also, and had to follow exactly the same procedure in regards
changing the device signature back and forth. I'm not sure why it uploads sketches to
1284 non-P using the 1284P signature.