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

oric_dan:
Hi leo, I don't understand. You're actually bridging the Rx and Tx pins using a 220K resistor?

No. I put a 175K in series on the line between the Arduino pin and the 1284 pin.
Arduino RX ------ R ------- RX0 1284P

What does that do? Where did that idea come from?

A friend of mine investigated the problem using an oscilloscope and he went to the result that the 1284p bootloader based on the Optiboot 4.5 works too early. It sends the reset and then start sending the datas on the line. A R introduces a little retard on the transmission, helping the bootloader to properly receive the datas.

Also, isn't 175K greater than the 1284P program space?

I was talking about R values, not firmware sizes :sweat_smile:

Also, I don't understand why the UNO board is in there during sketch uploading. ??

I don't have an USB/serial board, so I removed the chip from my Arduino and I use the Atmega8U2 as a USB/serial converter.

Also, I think the 1284P optiboot uses 115,200.

The Optiboot 4.5 works at 115,200, the other bootloader included in the maniacbug's core is based on the Stk500v2 bootloader from Atmel, also used on oldest Arduinos (like 2009). It works at 57,600 and has a better management of the timings.

So, I don't understand anything here. [early morning] ?????

I hope I have explained better :wink:

A friend of mine investigated the problem using an oscilloscope and he went to the result that the 1284p bootloader based on the Optiboot 4.5 works too early. It sends the reset and then start sending the datas on the line. A R introduces a little retard on the transmission, helping the bootloader to properly receive the datas.

This sounds technically incorrect on many levels. The resistor may be acting as a low pass filter element in conjunction with the Rx input pin capacitance but that is all, there is no 'delay' possible otherwise. So if this does help then it's just a simpler one component low pass filter design, just like the resistor/cap low pass filter 'solution'.

Lefty

retrolefty:
This sounds technically incorrect on many levels. The resistor may be acting as a low pass filter element in conjunction with the Rx input pin capacitance but that is all, there is no 'delay' possible otherwise. So if this does help then it's just a simpler one component low pass filter design, just like the resistor/cap low pass filter 'solution'.

Lefty

It did help. Your explanation sounds correct. I didn't think about the internal capacitance of the pin.

BTW I solved using the bootloader based on the Stk500v2 code included in the maniacbug's package. Burning that bootloader I can upload a sketch with no external components.

leo72:

retrolefty:
This sounds technically incorrect on many levels. The resistor may be acting as a low pass filter element in conjunction with the Rx input pin capacitance but that is all, there is no 'delay' possible otherwise. So if this does help then it's just a simpler one component low pass filter design, just like the resistor/cap low pass filter 'solution'.

Lefty

It did help. Your explanation sounds correct. I didn't think about the internal capacitance of the pin.

BTW I solved using the bootloader based on the Stk500v2 code included in the maniacbug's package. Burning that bootloader I can upload a sketch with no external components.

leo, thanks for the explanation. I guess I read everything backwards! With a 175K series-R and
talk of slowing things down, I would immediately assume it's a low-pass filter in conjunction
with the RX0 pin input impedance. Eg, R*C = 175K * 20pF = 3.5 usec approx. And the 10K,
100pF filter others are using would have similar effect.

As mentioned, I've been using maniacbug's optiboot at 115.2, and no low-pass, and have not
worried about any reset delays, and have had no problems with anything. And my 1284 test
board is a jumble of wires. So, still a little fuzzy about what's going on with everyone else.

I would think one could try patching maniacbug's optiboot to check for a delay problem.

I've taken my old 1284p off the shelf and tried to flash the mighty-optiboot (hex latest from repo, IDE 1.5.1r2, 16MHz xtal, 115k2), with no success. I am using Usbasp, optiboot_atmega1284p.hex from repo and from the forum topics as well (not compiled by myself yet), and all possible fuses settings.
When burned in I do not see the led on pin 13 flashing few times (D13 on mighty pin layout I guess) after a reset and the upload of a sketch shows:

..Binary sketch size: 15,508 bytes (of a 130,048 byte maximum)
processing.app.debug.RunnerException
	at processing.app.debug.BasicUploader.uploadUsingPreferences(BasicUploader.java:126)
	at processing.app.Sketch.upload(Sketch.java:1664)
	at processing.app.Sketch.exportApplet(Sketch.java:1623)
	at processing.app.Sketch.exportApplet(Sketch.java:1595)
	at processing.app.Editor$DefaultExportHandler.run(Editor.java:2393)
	at java.lang.Thread.run(Thread.java:619)

"Upload Using Programmer" (with the same Usbasp) works fine.
A similar setup with 328p and optiboot works fine here as well. It seems to me the 1284p' optiboot hex file includes something my programmer cannot process properly..

PS: when trying to burn the bootloader via Usbasp from IDE (Tools/Burn Bootloader) I get:

processing.app.debug.RunnerException
	at processing.app.debug.BasicUploader.burnBootloader(BasicUploader.java:288)
	at processing.app.Editor$47.run(Editor.java:2509)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

And my board:

##############################################################
mighty_opt.name=Mighty 1284p 16MHz using Optiboot
mighty_opt.upload.protocol=arduino
mighty_opt.upload.maximum_size=130048
mighty_opt.upload.speed=115200
mighty_opt.bootloader.low_fuses=0xff
mighty_opt.bootloader.high_fuses=0xde
mighty_opt.bootloader.extended_fuses=0xfd
#mighty_opt.bootloader.path=optiboot1284p
mighty_opt.bootloader.file=optiboot1284p/optiboot_atmega1284p.hex
mighty_opt.bootloader.unlock_bits=0x3F
mighty_opt.bootloader.lock_bits=0x0F
mighty_opt.build.mcu=atmega1284p
mighty_opt.build.f_cpu=16000000L
#mighty_opt.build.core=arduino:arduino
mighty_opt.build.core=standard1284p
mighty_opt.build.variant=mighty

I have a USBtiny programmer that also fails to burn the optiboot onto a 1284P chip, but can do it for a 644P chip. But this is a known limitation of the USBtiny programmer not being able to handle addresses higher then 64KB. But I was able using a standard arduino board to burn the optiboot loader onto the 1284P chip using Nick's great sketch. It has the optiboot loader code built into the sketch so the IDE is not involved.

Lefty

Frankly, I am not aware of the fact Usbasp cannot flash at the top addresses. I used it with amforth for example - afaik it stores code on the top within the bootloader section - no issues ever..
So burned in with Nick's code:

Atmega chip programmer.
Written by Nick Gammon.
Entered programming mode OK.
Signature = 0x1E 0x97 0x05
Processor = ATmega1284P
Flash memory size = 131072 bytes.
LFuse = 0xFF
HFuse = 0xDE
EFuse = 0xFD
Lock byte = 0xFF
Clock calibration = 0x53
Bootloader address = 0x1FC00
Bootloader length = 508 bytes.
Type 'V' to verify, or 'G' to program the chip with the bootloader ...
Erasing chip ...
Writing bootloader ...
Committing page starting at 0x1FC00
Committing page starting at 0x1FD00
Written.
Verifying ...
No errors found.
Writing fuses ...
LFuse = 0xFF
HFuse = 0xDE
EFuse = 0xFD
Lock byte = 0xEF
Clock calibration = 0x53
Done.
Type 'C' when ready to continue with another chip ...

And uploading the working sketch:

Binary sketch size: 15,558 bytes (of a 130,048 byte maximum)
processing.app.debug.RunnerException
	at processing.app.debug.BasicUploader.uploadUsingPreferences(BasicUploader.java:126)
	at processing.app.Sketch.upload(Sketch.java:1664)
	at processing.app.Sketch.exportApplet(Sketch.java:1623)
	at processing.app.Sketch.exportApplet(Sketch.java:1595)
	at processing.app.Editor$DefaultExportHandler.run(Editor.java:2393)
	at java.lang.Thread.run(Thread.java:619)

:~

pito:
Frankly, I am not aware of the fact Usbasp cannot flash at the top addresses. I used it with amforth for example - afaik it stores code on the top within the bootloader section - no issues ever..

And I too don't know if USBasp has such a limitation or not, just reporting that a USBtiny does and a simple work around for me was using an arduino board and Nick's program.

Lefty

I knew that USBasp didn't have the 64 kB limit.
This is from the changelog of the last version of the firmware:

usbasp.2011-05-28 (v1.4)

  • added support for controllers with flash >128kb (by Slawomir Fra?)

Ok, an interesting stuff, indeed.

  1. LED is on PB0 on my board, it flashes after reset, all programmers work fine :slight_smile:
  2. I did some editing of the avrdudeconf (added resetdelay = 15, similar to uno, and added ..tool=avrdude into boards) - that causes the avrdude resets the BT pin32 (aka dtr) now before the upload (I am using a BT module).

So the upload started, but finished with errors already published here. I did about 70 uploads of a 15kB sketch and my current findings are as follows (chip date 1027, breadboard, good decoupled, short wires (5cm long Rx, Tx to BT), no crossing with other signals or crystal):

  1. without pull up/down resistor on RX and w/ short wires the probability of a successful upload ~10%
  2. with pull-up/down 10k res on Rx - about 40%
  3. with serial 10k in RX - 100% upload, even with a 20cm long Rx wire and while the wire touched/hold during the upload (the 20cm wire at the 1284p's Rx pin side)
  4. w/o the serial 10k and with 20cm long Rx wire no luck.

That behavior might be caused, except "Rx pin signal/noise sensitivity", by a reversal of the 1284p's Rx input pin direction, even for a very short time, thus it fires against the other output (ftdi's or BT's Tx), and when the current peak is not limited (ie. by a serial resistor) it flips internally into an undefined state. Hopefully the bootloader does not change the Rx direction (or switches internal pullups on/off on that pin) somewhere in the code..

I did following experiment - 58cm long Rx wire, passed beneath the crystal, did few loops with it creating a mess :slight_smile: with 10k serial resistor wired as follows:

BTmodule_Tx --10kohm------>>---------58cm_wire------->>-----Crystal---->>----Rx pin 1284p

Uploaded an 127kB large sketch:

Binary sketch size: 127,052 bytes (of a 130,048 byte maximum)

Done 12x while touching the 58cm long wire during the upload from time to time - upload 100% ok. I did not test the code actually works, though :).

Solved?
With Low Fuse= F7 (Full Swing Oscillator 16K CK + 45ms) I cannot reproduce the upload errors anymore (the 10k serial resistor is not needed). It could be the 1284p operated @16MHz and 3V3 needs full swing (more power), otherwise the nearby RX pin may influence (modulate) the crystal oscillator frequency (especially with the DIP package with larger capacitance between the pins) and it comes to errors then..
PS: XTAL1 pin13 (RX is 14) - is the input of the crystal oscillator (high impedance, easy to modulate), would be better to have XTAL2 pin - the oscillator output - there (low impedance, harder to modulate)..

FYI - a simulation - signal from FTDI to the Rx pin, and Rx coupled via a parasitic capacitance to the XTAL1 pin of the 1284p's oscillator. For 3 parasitic capacitances - 1pF, 5pF, 10pF. You may see the effect on the frequency when the rising edge of the Rx signal comes in. May behave differently - depends on the gate (here 4011 gate model used), xtal (??), etc. parameters used.

Disclaimer: this is only a simple simulation with parts with different parameters as the 1284p probably includes. For demonstration purposes only. No warranties of any kind.

And the same for 5pF parasitic capacitance between the pins and 200ohm (no resistor), 10k, 200k serial resistor. It seems the 200k does not create a glitch in the oscillation (in this simulation).

Disclaimer: simple simulation only, with different parts as included within 1284p. For demo purposes only. No warranties of any kind.

PS: The very bottom picture is probably the most realistic simulation out of all above- with 4049 inverter simulating the 1284p oscillator with more power (full swing), and 10pF capacitance between the RX and XTAL1 pins. The oscillator period changed from 127.1ns to 135.4ns after the Rx' rising edge (thus the frequency)..

pito:
Solved?
With Low Fuse= F7 (Full Swing Oscillator 16K CK + 45ms) I cannot reproduce the upload errors anymore (the 10k serial resistor is not needed). It could be the 1284p operated @16MHz and 3V3 needs full swing (more power), otherwise the nearby RX pin may influence (modulate) the crystal oscillator frequency (especially with the DIP package with larger capacitance between the pins) and it comes to errors then..
PS: XTAL1 pin13 (RX is 14) - is the input of the crystal oscillator (high impedance, easy to modulate), would be better to have XTAL2 pin - the oscillator output - there (low impedance, harder to modulate)..

Huh! It's extremely cool that you've been carrying on with this problem while the rest of us have
been sleeping!

I don't know anything about USBasp or the ATmega fuses, and can barely understand the
convoluted description of the latter in the 1284 d/s, but you may have solved the problem.
Ref Table 9-1, maniacbug's boards.txt setup uses the low-power oscillator, low fuses = 0xFF,
instead of full swing oscillator, low-fuses = 0xF7 and there lies the RX0 sensitivity problem.
Plus, possibly the XTAL1 is in the wrong place.

Sheesh, can this endless muckup on 7 continents be that simple? !!!

I am using it just now w/o the resistor on a noisy breadboard with F7 and it works fine, no issues yet.. :wink:

BTW, the 328p arduinos are lucky not to be affected by the issue as well as the Rx and Tx pins are far away off the XTAL1 pin. Moreover, XTAL1 (the critical sensitive crystal oscillator input) is flipped around against the 1284p and close to GND - GND acts as a shielding (GOOD)! See below..

IMHO the issue severity depends on the design (parasitic capacitance), crystal parameters, 2 crystal capacitors values, and how off is the actual crystal frequency from the recommended ie for 115k2:

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 is my current understanding :stuck_out_tongue: If Atmel plans a new die revision, I would recommend them to swap the oscillator pins, my invoice will follow :slight_smile:

328p vs 1284p OSC.jpg

Good analysis, I think. Funny how Atmel flipped XTAL1,2 around between the 328 and 1284.
Also, 2.1 and 3.7% errors are on the edge of reliability, AFAIAC.

BTW - hand wired constructions usually have less parasitic capacitances as the PCBs do..
BTW2 - the capacitance between two adjacent rows on a solder-less breadboard is around 3.5pF..

breadb.jpg

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..