next topic »

[Reply #60 on:]

Ok, here is some progress. I tried lefty's sketch, with arraysize set = 4000 to 7000.
I uploaded a dozen or so times, using both the FTDI Friend and the FTDI cable, and
it never failed to burn and verify properly. I still have the RX0 wirewrap wire
running inbetween the xtal pins, and no low-pass filter on the RX0 pin.

arraysize = 4000 gives a 67808 byte file, and 7000 gives 115808 bytes. Upload and
verify takes 70-sec for the 115808 byte file.

One thing of interest - for arraysize > 4000 or so, the sketch no longer works correctly,
ie Led 13 does not flash after uploading. At 4000 and below, Led 13 blinks ok.

[Reply #61 on:]

 This works on the 1284P:

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= 4000;  // 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);
  Serial.begin(115200);
   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);
  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
}

Code:

Binary sketch size: 67,994 bytes (of a 130,048 byte maximum)

Estimated used SRAM memory: 365 bytes

This code with a bigger array, loads OK but, does not  run:

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= 5000;  // 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);
  Serial.begin(115200);
   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);
  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
}

Code:

Binary sketch size: 83,994 bytes (of a 130,048 byte maximum)

Estimated used SRAM memory: 365 bytes

[Reply #62 on:]

One thing of interest - for arraysize > 4000 or so, the sketch no longer works correctly,
ie Led 13 does not flash after uploading. At 4000 and below, Led 13 blinks ok.

I agree.

[Reply #63 on:]

Ok, here is some progress. I tried lefty's sketch, with arraysize set = 4000 to 7000.
I uploaded a dozen or so times, using both the FTDI Friend and the FTDI cable, and
it never failed to burn and verify properly. I still have the RX0 wirewrap wire
running inbetween the xtal pins, and no low-pass filter on the RX0 pin.

arraysize = 4000 gives a 67808 byte file, and 7000 gives 115808 bytes. Upload and
verify takes 70-sec for the 115808 byte file.

One thing of interest - for arraysize > 4000 or so, the sketch no longer works correctly,
ie Led 13 does not flash after uploading. At 4000 and below, Led 13 blinks ok.

Yes, that is a problem, and it's very likely that the sketch is not being loaded correctly after a certain size is reached even though it's less then maximum flash memory size. There is no AVRDUDE error reported after the upload, but obviously the blink program is not running after the upload. It's believed to be a bug in the bootloaders for large (but still legally sized) sketches. For instance when using the Uno's bootloader one can load up a sketch right up to near the flash memory maximum size limit, but with a mega1280 I can't even get close to near max size. Coding Badly is of the opinion that is a bug in older bootloaders and their interaction with AVRDUDE on large code size uploads. So if the 1284P bootloader is just a recompilation based on one of the older mega bootloader programs it may have 'inherited' the same problem. This should be investigated further but I'm afraid I'm not knowledgeable enough in software/bootloaders to be a direct help other then testing.

 I guess a first step is for someone to try a different method to developing large sketch sizes just to make sure it's not my sketch causing the problem symptom. Anyone up for the challenge?

Lefty

[Reply #64 on:]

For arraysize > 4000, the program does not appear to start. The Serial.print()
statements in setup() do not print either. I also added Serial.begin() that lefty left
out. So, out of one frying pan and into the next.

[Reply #65 on:]

avrdude has probably been patched so many times, it's probably a wonder it works
at all. There is probably an int somewheres where there should be a long. arraysize
of 4000 gives a 67808 byte size file that is just over the 16-bit boundary.

Do you suppose the .hex file address indexing is handled correctly during compilation?

[Reply #66 on:]

For arraysize > 4000, the program does not appear to start. The Serial.print()
statements in setup() do not print either. I also added Serial.begin() that lefty left
out. So, out of one frying pan and into the next.

Actually I didn't add the serial statements to have them output anything useful as that is why there is no Serial.begin(), it's a way someone showed me to keep the compiler from optimizing away the otherwise unused arrays. It the arrays are not referenced in the sketch they won't be created in the final compilation and thus the sketch size wont' grow in size.

Lefty

[Reply #67 on:]

avrdude has probably been patched so many times, it's probably a wonder it works
at all. There is probably an int somewheres where there should be a long. arraysize
of 4000 gives a 67808 byte size file that is just over the 16-bit boundary.

Do you suppose the .hex file address indexing is handled correctly during compilation?

I don't know, but I really do believe it's a bootloader/AVRDUDE legacy bug that has not been fully explored or explained let alone solved for the larger mega size chips when using AVRDUDE. Testing with a 644P chip showed no problem loading up to very near it's flash limit size, so I think the problem is when using sketches larger then the 644P size is.

Lefty

[Reply #68 on:]

I remove programem and made the array smaller, although it should fit the chip it uploads but, does not work.

Code:

Binary sketch size: 3,994 bytes (of a 130,048 byte maximum)

Estimated used SRAM memory: 48,365 bytes

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= 3000;  // value to mostly fill avalible flash capacity

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

// the setup routine runs once when you press reset:
void setup() {               
  // initialize the digital pin as an output.
  pinMode(led, OUTPUT);
  Serial.begin(115200);
   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);
  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
}

[Reply #69 on:]

 SRAM memory issue?????

[Reply #70 on:]

So, I assume the mega2560 chips also have problems above 64KB/whatever?

[Reply #71 on:]

I remove programem and made the array smaller, although it should fit the chip it uploads but, does not work.

Code:
Binary sketch size: 3,994 bytes (of a 130,048 byte maximum)

Estimated used SRAM memory: 48,365 bytes

Well that isn't testing with rather large flash sizes and as the 1284P does not have SRAM that big I don't think it's a legit test to hang one's hat on. We need another sketch that creates large sketch flash sizes independent of my sketch to verify it's not a sketch problem but rather just a sketch size problem.

Lefty

[Reply #72 on:]

So, I assume the mega2560 chips also have problems above 64KB/whatever?

I would bet so, but don't have a mega2560 board to test, just a arduino mega1280 and a seeeduino mega1280 board that both choke on larger sketch sizes.

Lefty

[Reply #73 on:]

Yes, that is a problem, and it's very likely that the sketch is not being loaded correctly after a certain size is reached even though it's less then maximum flash memory size. There is no AVRDUDE error reported after the upload, but obviously the blink program is not running after the upload. It's believed to be a bug in the bootloaders for large (but still legally sized) sketches. For instance when using the Uno's bootloader one can load up a sketch right up to near the flash memory maximum size limit, but with a mega1280 I can't even get close to near max size. Coding Badly is of the opinion that is a bug in older bootloaders and their interaction with AVRDUDE on large code size uploads. So if the 1284P bootloader is just a recompilation based on one of the older mega bootloader programs it may have 'inherited' the same problem. This should be investigated further but I'm afraid I'm not knowledgeable enough in software/bootloaders to be a direct help other then testing.

 I guess a first step is for someone to try a different method to developing large sketch sizes just to make sure it's not my sketch causing the problem symptom. Anyone up for the challenge?

Lefty

There's a problem related to a bug inside the GNU avr-gcc compiler. If I remember well, the compiler cannot create code that can directly access data in FLASH is it is stored over the 64 kB limit. Latest versions of avr-gcc aren't affected by this bug, the one that is included with the Ardino IDE is.
You can upgrade the Avr toolchain to fix it. I did it for my Linux box.

[Reply #74 on:]

SRAM memory issue?????

Yeah, 1284 has only 16KB of SRAM. Setting arraysize up to 960 = 4*4*960 = 15360 bytes
works, but arraysize = 1000 crashes, since there isn't room left for the background functions
and serial buffers.