[Solved!]UnXplained resetting of ATmega328p

The code works all fine! BUT 8)

So the problem is related with the functioning of the button that is linked with the interrupt 0 and when it is pressed it gets the uC out from no matter what its doing to handle the time recording in the interrupt function that is the clickReader() and then it is [u]supposed to change the length of the LED strip based on the time difference between the button presses which it does but after the code changes the length and completes one iteration of animation movement until the end of the strip the uC restarts????[/u]

here's how the strip Animates:

http://www.youtube.com/watch?v=LPDYC88DTlA

CODE attached because 9500 limit crossed!

You have an awful lot going on in the interrupt handler, including unnecessary floating point arithmetic. You access a lot of variables that are not declared volatile. Those same variables are accessed in other functions, which means that they should be volatile.

PaulS: You have an awful lot going on in the interrupt handler, including unnecessary floating point arithmetic. You access a lot of variables that are not declared volatile. Those same variables are accessed in other functions, which means that they should be volatile.

Also a lot of them are not atomic operations, so you should really be using critical sections in your main program when accessing them.

#define STRIP_LENGTH 160 //160 LEDs on this strip
...
long strip_colors[STRIP_LENGTH], this_led_color;
...
const long sinArray1[32] = { 
...
const long sinArray2[32] = { 
...
const long sinArray[32] = { 
...
const long sinArray_lb[32] = { 
...
const long sinArray_try[32] = { 
...
const long sinArray3[32] = { 
...
const long sinArray4[32] = {

I wouldn't be surprised if you are running out of memory. You hardly need a long type to hold such small numbers.

Don't rely on "free memory" routines. Without a memory manager they are guesses at best.

You should move all of your Serial.print()s to use the F() macro.

Turned all the variables into volatile which are shared in the interrupt routine and with that of the loop().

volatile unsigned long prevValue , currValue; //Addup = 0;//, Addup_2 = 16777215;// commented out functions use them!
volatile long differential;
volatile float startTime, endTime;
volatile boolean checkBUTTON;
volatile int counter;

also changed all the arrays to type unsigned int 32 bit because anyways the 24bits are used to 32 bitter int needs to be used.

same result.

I have the MemoryFree library installed! shall I check the ram usage?

I THINk long is half as light as compared to u_int32 so switching back

I tested again and realised that till 35leds it works all fine but if the animation gets bigger than that then it restarts the uC after the loop is completed!

for(int a = 0; a <= 160; a++){
    if(LEDlength_changer == true){
      fill_color(0xFFFFFF, a, a+size2);

I’d follow through on those three lines if I were you, looking very carefully for array accesses

for(int a = 0; a <= 160; a++){
    if(LEDlength_changer == true){
      fill_color(0xFFFFFF, a, a+size2);

These used to work flawlessly and on your recommendation I again checked them for any possible errors but still it seems fine.

I think the only thing here is the RAM

So, what happens in “fill_color” when a == 160?
That “<=” looks very dangerous.
(BTW, you have given a nice name to 160 - why don’t you use it?)

So, what happens in "fill_color" when a == 160?

Simple it just restarts.

I think is plain SRAM shortage as LED animation works with max 35 leds chunk and with longer than this the animation just moves one time and loop never gets reactivated while theres no such problem till 35 leds.

The SRAM might be overloaded with pushing out 24bit data for each LED color and beyond 35 leds the stack stucks!

Simple it just restarts

Because "set()" is writing off the end of "strip_colors" ?

Because "set()" is writing off the end of "strip_colors" ?

yes

So, bug found?

So, bug found?

No

You don't think that writing off the end of an array might be, how shall I put this, unwanted behaviour?

You don’t think that writing off the end of an array might be, how shall I put this, unwanted behaviour?

I think I didn’t get what you exactly mean by writing off?
How it can relate to restarting of the uC anyways! I don’t think so it should be restarting the uC for this problem

Your array "strip_colors" is defined to have 160 elements

#define STRIP_LENGTH 160 //160 LEDs on this strip
...
long strip_colors[STRIP_LENGTH],

so, valid indices are 0 to 159 inclusive. Writing off the end means using indices like 160 and above.

Also, your tables "sinArray.." should all be of type "byte" (unsigned char, uint8 etc) and should be in PROGMEM

Writing off the end means using indices like 160 and above.

okay so you mean this a+size2 part that takes the count over 160

BUT if this would have been the contributing factor then every iteration whether its 19 leds or 30 leds works out through that system and that loop then in that case this problem would have been there even in the case where 30 leds are revolving in an animated way!

I'm not going to argue the behaviour of a system that I cannot see, I'm just pointing out bugs. I also don't rationalise the behaviour of systems that stomp on memory they don't own.