next topic »

[Reply #135 on:]

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.

[Reply #136 on:]

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

[Reply #137 on:]

Code:

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.

[Reply #138 on:]

The alternate fuse setting was mentioned way back in http://arduino.cc/forum/index.php/topic,109550.msg902341.html#msg902341
But did not solve all problems.

[Reply #139 on:]

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

[Reply #140 on:]

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 :-(
Of course, I also thought I had already changed in the the Optiboot repository makefiles, and it isn't changed there either!  Sigh.

[Reply #141 on:]

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

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.

[Reply #142 on:]

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!

[Reply #143 on:]

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.

[Reply #144 on:]

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.

[Reply #145 on:]

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

[Reply #146 on:]

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

[Reply #147 on:]

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.

[Reply #148 on:]

its a bootloader thing

[Reply #149 on:]

Hello dude,
    I'm testing Mighty 1284p 16MHz Optiboot with Arduino IDE v1.0. I use FTDI usb-serial converter to upload the sketch. when I upload the following sketch, the maximum value of "arraysize" is 4070 while led blinking?

Code:

#include <avr/pgmspace.h>   //To store arrays into flash rather then SRAM
// Simple sketch to create large sketch sizes for testing purposes
/*
  Blink
  Turns on an LED on for one second, then off for one second, repeatedly.
 
  This example code is in the public domain.
 */
 
// Pin 13 has an LED connected on most Arduino boards.
// give it a name:
int led = 13;

/*
 Make arraysize = to 1500 for 328P chip, 4000 for 1280P chip?,
 3600 for 644P chip, xxxx for 1284P,  etc.
*/
const int arraysize= 7700;  // value to mostly fill avalible flash capacity

long myInts0[arraysize] PROGMEM = {};  //Store initilized array into flash memory
long myInts1[arraysize] PROGMEM = {};
long myInts2[arraysize] PROGMEM = {};
long myInts3[arraysize] PROGMEM = {};

// the setup routine runs once when you press reset:
void setup() {                
  // initialize the digital pin as an output.
  pinMode(led, OUTPUT);
  int i = random(0,arraysize);      // Work around any optimization for constant values
  Serial.print(myInts0[i]);         //  Access some random element so the array can't be optimized away.
  Serial.print(myInts1[i]);         //  Access some random element so the array can't be optimized away.
  Serial.print(myInts2[i]);         //  Access some random element so the array can't be optimized away.
  Serial.print(myInts3[i]);         //  Access some random element so the array can't be optimized away.
}

// the loop routine runs over and over again forever:
void loop() {
  
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);               // wait for a second
}

And 'avrsize' is showing the usage...

Code:

AVR Memory Usage
----------------
Device: atmega1284p

Program:  127366 bytes (97.2% Full)
(.text + .data + .bootloader)

Data:        427 bytes (2.6% Full)
(.data + .bss + .noinit)

I can upload sketch size 127k (arraysize=7700) without error, but led is not blinking.    Meaning that it stuck somewhere.
When I change the value of "arraysize" = 4070 (69k byte), led is blinking. It's too bad.   Any idea?

Regards,
pak