Arduino USB upload stops half way through uploading with timeout_error

Hi All,

Help Please!

The attached code compiles fine :slight_smile: but when I upload it to my Mega2560 it starts to upload OK and then avrdude suddenly stops waiting for a response from the Arduino =(, I am running Windows 7, and have tested this sketch on two seperate arduino boards on two seperate PC’s with exactly the same results. I using the standard with Arduino IDE to compile and upload.

This code has been generated by a windows program for converting bitmaps into an LED Strip lightwand (this is the LPD8806 version). The sketch appears to work fine for some bitmaps and not others so I am guessing it is something to do with the a sequence of values in the Long arrays - but which one???

Thanks in advance

Phil

TestSketch1.pde (36.1 KB)

I'm no expert, still learning the Arduino language and environment, but if I were you I'd start by halving the size of the program (maybe the data part) to see if it is a data size problem.

Then slowly remove parts till the program loads.

I assume other simpler sketches work for you?

long lCntr[1];

? A one element array. How useful.

long buffer[STRIP_LENGTH];
long tmpbuffer[STRIP_LENGTH+1];

Why are these different sizes?

Hi,

The "long lCntr[1]" is because of using it as a pointer , I am not that familar with the PROGMEM statements and my 'C' programming knowledge is about 10 years out of date so I was just following some examples

Each strip_colors_x[] arrays holds a very simple compression of the LED's to light on a 96 LED light strip, basically making up a Bitmap of 96 high and 96 wide.

The first long in each strip_colors_x[] tells me how many different color elements are on each array line.
The rest of the 32bit longs on each array are broken down into :
First 8 bits = number of times to repeat the color
next 24 bit = Red,Green,Blue
so strip_colors_0[]={0x00000001,0x60000000} means only one color element in this strip with is hex 60 long (96 pixels) of 000000 (black or all LEDS off)

The reason the buffer and tmpbuffer are different sizes is simple tmpbuffer needs to hold the . The first long in each array line is the number of longs in that array, so I memcpy the first long of each arracy into lCntr to get the total number, then copy the whole array from program memory into ram tmpbuffer.

I then use the values I get from tmpbuffer (first 8 bits in number of colours, then 8 bits each for Red, Green, Blue) to populate buffer ready for sending out the LED strip.

I am more concerned about why it doesn't upload after it compiles perfectly well than how effiecient my code is

Thanks

if I were you I'd start by halving the size of the program (maybe the data part) to see if it is a data size problem.

Then slowly remove parts till the program loads.

Thanks - I did try that late last night and it appeared to be somewhere around strip_colors_50, I need to do more to diagnose it tonight.

I did read on one forum today that was dated 2006 that three exclamation marks can cause problems but that was supposidly fixed, I am at work at the moment so can't test it but I did see three hex 21's which is dec 33 (char !) on strip_color_51. So I am hoping this is the answer - has anybody else had similar problems??

It would be strange that a long value can cause the code to fail uploading though!

My suspicions were correct it was having !!! In the code even though this was in a long - as this was just bitmap data making it a different value wasnt a big deal but seems mad that it can stop an upload going to the mega2560 - anyway thanks for your help

philwright:
My suspicions were correct it was having !!! In the code even though this was in a long - as this was just bitmap data making it a different value wasnt a big deal but seems mad that it can stop an upload going to the mega2560 - anyway thanks for your help

Thanks for educating me, I did not know about the !!! problem! (!!)

   for(int x=0;x<STRIP_LENGTH;x=x+nCnt);
    {

Is that intentional?

There is no need for “blank_strip” - “buffer” is already zeroed, and even if you were going to use it more than one, “memset” would be more efficient.

philwright:

if I were you I'd start by halving the size of the program (maybe the data part) to see if it is a data size problem.

Then slowly remove parts till the program loads.

Thanks - I did try that late last night and it appeared to be somewhere around strip_colors_50, I need to do more to diagnose it tonight.

I did read on one forum today that was dated 2006 that three exclamation marks can cause problems but that was supposidly fixed, I am at work at the moment so can't test it but I did see three hex 21's which is dec 33 (char !) on strip_color_51. So I am hoping this is the answer - has anybody else had similar problems??

It would be strange that a long value can cause the code to fail uploading though!

You just saved my sanity.

Using the latest 1.0.5 and had a Serial.print line in my sketch with three exclamation marks.... THAT was the reason my Mega was stopping the upload and getting stuck. Would have probably try 100 other things before figuring this one out.

Thanks!!