next topic »

[Reply #90 on:]

In the end, after everything these mega1284 threads have been through, I'm still
not certain why many people are having the uploading problem. I haven't needed
the low-pass filter on RX0, and my tests earlier indicated I couldn't even reproduce
the upload problem by running the RX0 line directly through the crystal area, or
under and between the xtal pins. So ????
...........

However, I did discover a sensitivity that I forgot to mention earlier. On my mega1284
proto-test board, I am using a 6-pin header to connect the FTDI cable and FTDI Friend.
Otherwise, the RX0 pin was floating.

I found you "definitely" need to have a pullup on RX0, for when the FTDI interface is
not connected. This stands to reason, of course, as you will otherwise get noise
injected on that pin. However, unlike essentially every "other" pin on the chip, which
will be floating unless specifically terminated, noise coming in on RX0 will actually reset
the chip.

I did this test by touching each of the 1284 pins with my finger [my usual try to kill
the chip test]. Doing this had no effect for other pins, but touching the floating RX0
pin "always" reset the processor immediately. So, this is interesting....

I believe this is the same failure mode/symptom that people having trouble uploading via RX0, noise being injected via RX0 corrupting internal data bus.

Lefty

[Reply #91 on:]

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.

[Reply #92 on:]

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 

[Reply #93 on:]

i can verify atmel is correct stating that uart0 is a customer layout problem. a client came to me with an m1284p board that failed to upload and we found adding a guard ring around the pin fixed it. there were several other avrs showing similar problems over the years, 90s1200 and 90s8515 being infamous examples. in every case proper layout fixed it.

[Reply #94 on:]

John, do you have any idea if adding a guard ring around the next-door crystal cktry will
have a similar effect?

[Reply #95 on:]

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.

[Reply #96 on:]

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.

[Reply #97 on:]

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

[Reply #98 on:]

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.

[Reply #99 on:]

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?

[Reply #100 on:]

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.

[Reply #101 on:]

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

[Reply #102 on:]

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  

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.
 

[Reply #103 on:]

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  

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.
  

[Reply #104 on:]

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.