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

most of the dozen or so occurences ive seen were spurious interrupts and resets due to fast signals nearby and not so much crystal issues. in the case i just mentioned and most others autorouted fill pretty much served as guard ring for the clock pins. maybe thats why this did not seems to be the cause for us. i do know there were several choices for a fix that worked and narrowed it down to resistor (no cap) right on the rx pin or ground ring. chose the latter because partlist and schematic stayed the same and much easier to refit existing boards.

A dozen - that's pretty serious. Can you explain the bit about "fast signals nearby" a little more.
What exactly are you talking about here? I'm not even sure what fast signals on an Arduino even
means, as I/O is pretty slow in general. The crystal oscillator is by far the fastest. Thanks.

A couple of months ago I had a PCB made for the ATmega1284 by Seeed. I've only been playing with electronics/Arduino for a year. So I was a bit nervous, would it work? To make it even more interesting it's powered by a LM2596 switch mode voltage regulator. I have now used the board extensively, uploaded hundreds of sketches and have not had any issues. Maybe I'm lucky? I even put the crystal and caps inside the socket. The board has an I2C logic level converter to talk to 3V3 I2C sensors and a header for a nRF24L01 wireless module. I have not tried uploading really big sketch. My biggest sketch is 30kb, anyone have an example of a really big sketch (+64kb) that I could upload?
Pic of my board: http://www.bajdi.com/wp-content/uploads/2012/12/bajduino-mega-3A.jpg

oric_dan:
A dozen - that's pretty serious. Can you explain the bit about "fast signals nearby" a little more.
What exactly are you talking about here? I'm not even sure what fast signals on an Arduino even
means, as I/O is pretty slow in general. The crystal oscillator is by far the fastest. Thanks.

actually avr has faster io than most other chips of its type. not high frequency, high drive capability. it contributes to fast rise and fall times and avr are very high current. the xtl signal is quite slow by comparison and may actually be a sine wave if ckopt aint enabled.

but this is not what im talking about. it was external signals coming from outside the chip and not so much self-interference. specially if there were long wires from external serial. even 50ohm or 100ohm suppressed so im guessing its transmission line ringing. probably really skinny hv pulses causing clamp zeners to forward bias. that can show up in completely unrelated areas of the chip and totally unpredictable. even 100k+ worked but because im fond of avr pull-ups 1-2k would be a better choice for the series resistor there. but like i said we decided on pcb shielding instead in the case of the m1284p. btw as others noted m1284 in the same socket did not show the problem.

Pic of my board: http://www.bajdi.com/wp-content/uploads/2012/12/bajduino-mega-3A.jpg

Interesting, I see you're using the 1284P chip here, which is the one people have been having all
the trouble with. So, you have an smt crystal and caps underneath the chip?

but this is not what im talking about. it was external signals coming from outside the chip and not so much self-interference. specially if there were long wires from external serial. even 50ohm or 100ohm suppressed so im guessing its transmission line ringing. probably really skinny hv pulses causing clamp zeners to forward bias. that can show up in completely unrelated areas of the chip and totally unpredictable. even 100k+ worked but because im fond of avr pull-ups 1-2k would be a better choice for the series resistor there. but like i said we decided on pcb shielding instead in the case of the m1284p. btw as others noted m1284 in the same socket did not show the problem.

Ok, thanks, John, external signals. "even 50ohm or 100ohm suppressed" - is this on the pcb or at
the source? There is such a thing as "source series termination", which is using a 50R series-R at
the source end to quench ringing on a long line, and it works really really well.

There is also an issue with the RX0 pin floating. On my proto-test pcb, I use an FTDI cable, and
when it was disconnected, I found the chip would reset and reboot by touching the RX0 pin [no
other pins did this, except sometimes the xtal pins]. A pullup fixed the problem.

oric_dan:

Pic of my board: http://www.bajdi.com/wp-content/uploads/2012/12/bajduino-mega-3A.jpg

Interesting, I see you're using the 1284P chip here, which is the one people have been having all
the trouble with. So, you have an smt crystal and caps underneath the chip?

It's a 16MHz low profile through the hole crystal from Tayda electronics (I buy most of my stuff there). Inside the socket there is also a small inductor and capacitor (between vcc and avcc).

leo72:

oric_dan:

leo72:
I read here that a 1283P owner suggested that these RX0 pin problems could be related to the PicoPower version of the chip.
Do you have a "non-P" chip to try if it shows the same behaviour (I don't have it)?

leo, so far I have been using only the 1284 "non-P" version, and have had no problems
with those. Today I ordered some of the 1284P chips, so will see how those work in a
couple of days.

OK. I stay tuned :wink:

Alright, I received 4 atmega1284P chips today, data code = 1247. Definitely got the "P"
version this time. I've uploaded my large 84Kbyte program now about a dozen times total
into the 4 chips. Still using my proto-shield turned 1284 test board. I am not using a low-
pass filter on RX0.

Bad news is, I cannot repeat the upload and RX0 sensitivity problems that other people
have been seeing. Good news is, I cannot repeat the upload and RX0 sensitivity problems
that other people have been seeing. So, where I live, it always works, both non-P [data code
1216] and P [data code 1247] version chips.

oric_dan:

leo72:

oric_dan:

leo72:
I read here that a 1283P owner suggested that these RX0 pin problems could be related to the PicoPower version of the chip.
Do you have a "non-P" chip to try if it shows the same behaviour (I don't have it)?

leo, so far I have been using only the 1284 "non-P" version, and have had no problems
with those. Today I ordered some of the 1284P chips, so will see how those work in a
couple of days.

OK. I stay tuned :wink:

Alright, I received 4 atmega1284P chips today, data code = 1247. Definitely got the "P"
version this time. I've uploaded my large 84Kbyte program now about a dozen times total
into the 4 chips. Still using my proto-shield turned 1284 test board. I am not using a low-
pass filter on RX0.

Bad news is, I cannot repeat the upload and RX0 sensitivity problems that other people
have been seeing. Good news is, I cannot repeat the upload and RX0 sensitivity problems
that other people have been seeing. So, where I live, it always works, both non-P [data code
1216] and P [data code 1247] version chips.

Ah, but did you wait and try at a low tide? How about a full moon? Environmental effects can be hard to sort out sometimes.
:smiley:

Actually, the moon just hit full-phase here, but I don't know about so.cal. It has warmed up
greatly - a few days ago it was down to 8 degF at night, now it's not below freezing.

In any case, my plans are to use the 1284P chip, in order that I don't have to keep patching
avrdude.conf for the non-P version, and on my pcb layout, I added both a low-pass filter on
RX0, plus a guard ring around the pin, and also added a pullup on RX0 for when the FTDI
cable is not connected. Lastly, am hoping the weather doesn't change again.

Also, thanks for straightening me out on the variants pins_arduino.h files. I now realize the
same optibootloader is burned into all the variants, and this file is only used during compilation.

During the last days I did a lot of tests trying to solve the problem.
If you're using the Mighty-1284p files by maniacbug, select the board "Mighty 1284p 16 MHz w/Optiboot" then put a 220K resistor in series on the line beetween the FT232 TX and the 1284p RX0 pins.

If you're using the "Original Mighty 1284p" board, then you could try with a 120K R. Or, maybe, without components.

With my 1284P, I was able to flash a sketch using a 175K over the line beetween my Arduino UNO R1 RX pin and the 1284P RX0 pin when I chose the 1284p board. Using the "Original Mighty" board, I was able to flash a sketch with no extra components. Using this board, remember to check the upload speed in file boards.txt: it has to be set a 57600 (it is by default).

leo72:
During the last days I did a lot of tests trying to solve the problem.
If you're using the Mighty-1284p files by maniacbug, select the board "Mighty 1284p 16 MHz w/Optiboot" then put a 220K resistor in series on the line beetween the FT232 TX and the 1284p RX0 pins.

If you're using the "Original Mighty 1284p" board, then you could try with a 120K R. Or, maybe, without components.

With my 1284P, I was able to flash a sketch using a 175K over the line beetween my Arduino UNO R1 RX pin and the 1284P RX0 pin when I chose the 1284p board. Using the "Original Mighty" board, I was able to flash a sketch with no extra components. Using this board, remember to check the upload speed in file boards.txt: it has to be set a 57600 (it is by default).

Hi leo, I don't understand. You're actually bridging the Rx and Tx pins using a 220K resistor?
What does that do? Where did that idea come from?

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

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

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

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

oric_dan:
Ok, thanks, John, external signals. "even 50ohm or 100ohm suppressed" - is this on the pcb or at
the source? There is such a thing as "source series termination", which is using a 50R series-R at
the source end to quench ringing on a long line, and it works really really well.

any long wires hanging directly off the pin can be a source of noise pulse pickup so the series resistor had to be right on the avr pin to solve the problem. and youre right about low value series being common. specially high speed dram bus where pico-seconds matter. but for the rx0 problem 1k or 2k is better. has added advantge of allowing direct connection to 12v rs232 equipment w/o issues.

and i saw the xtl pin reset too but not much you can do about that except dont touch them. :slight_smile:

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)

:~