atmega328P: stack problem ?

Go To Last Post
66 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tnx for mentioning me :)

I did not read through all 50 posts, just glanced briefly through them.

 

When you look through the code, then any pointers used, are suspicious, especially if shared with an ISR.

Right now I'm not thinking too clear, time for a nap I guess.

 

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

m.majid wrote:

autsel wrote:

The point is this, initially the project did not have an external eeprom and I used the internal eeprom of the ATMEGA and I was corrupted the data in the eeprom.
Also, about usart I did not use the interrupt in reception but I used a sobroutine with a timeout to simply read the buffer and I had the same problem.

 

So I put my hands on the circuit and put an external eeprom. Obviously the data in the external eeprom remain intact but the variables and constants are corrupted.

I tried to figure out how often your code writes the eeprom, I did not succeed to trace 13 status for each channel.
Only God and you know what your code does! ;)
.
I assume you do aware of limited write/erase cycles of eeproms which is 100,000 cycles for ATmega328P and 1,000,000 for AT24C64
.
Maybe you would also debug to make sure not crossing eeprom write cycle limits.

 

In number of writes on the eeprom is really limited, depends on how many times a user programs the device.
Getting to 1000 scriptures is really very challenging !!!

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:

Tnx for mentioning me :)

I did not read through all 50 posts, just glanced briefly through them.

 

When you look through the code, then any pointers used, are suspicious, especially if shared with an ISR.

Right now I'm not thinking too clear, time for a nap I guess.

 

 

I eagerly await your opinion.

 

 

In the meantime I ordered atmel-ICE which should be a debugger for AVR too via debugWire.

Then, I do not think it will be easy to debugger in assembler a program written in c.

 

I looked and read also about the logic analyzer...
I understood how it worked, but I did not understand how to do it. I tried but without success
I'll read more.

 

 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry I over looked #37:

autsel wrote:
the data in the external eeprom remain intact

.
I deviated because of #44 :
autsel wrote:
I take note.
In fact, I always lost the first bytes of the eeprom

.
Ok, you had eeprom issue at first with internal eeprom of ATmega328P,
but not any more issue with external eeprom AT24C64
You beleive it is variable corruption and you suspect stack.
.
#1
autsel wrote:
atmega328p lose values in the variables and/or in the constants

#37
autsel wrote:
but the variables and constants are corrupted.

Could you explain more details about how you established variables corrupted?
.
autsel wrote:
Program don't crash, beacause there is a led blinking every seconds, and it blink forever.

Maybe program stucks in main, then LED is blinking by timer.

Majid

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

m.majid wrote:

 

autsel wrote:
but the variables and constants are corrupted.

Could you explain more details about how you established variables corrupted? .

I try to send via 485 some variables every 2hours for test.

At a certain moment variables change value into value which makes no sense.

 

m.majid wrote:

autsel wrote:
Program don't crash, beacause there is a led blinking every seconds, and it blink forever.

Maybe program stucks in main, then LED is blinking by timer.

 

No stuck in main.
The button sometimes does not work anymore, sometimes work, but rs485 forever work correctly (sending  errata data values)
sometimes the pwm works abnormally because of the corrupt gamma table constant (before write in flash)

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I had a very short look at the code.

 

Are you 100% sure that none of the indexes are out of range?

 

I would put a check before all writes where indexes are used.

 

Also your RX routine return 0 if there is a timeout, if you receive a 0 it also return a 0! (that is why normal get routines return 16 bit so it can return -1 for an error) 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I missed this during the last week (perhaps the thread title wasn't interesting enough).

 

But I get the feeling this an XY problem unfolding here:

 

https://en.wikipedia.org/wiki/XY_problem

 

Even after reading all the posts so  far I still could not tell whether this is a problem of SRAM corruption of EEPROM corruption. Or even the conditions under which the corruption occurs.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:
I had a very short look at the code. Are you 100% sure that none of the indexes are out of range? I would put a check before all writes where indexes are used. Also your RX routine return 0 if there is a timeout, if you receive a 0 it also return a 0! (that is why normal get routines return 16 bit so it can return -1 for an error)

 

I'm sure 100% that are not out of range indexes. There are only 2, buffer[] and ch[][].

Which routines are you referring to with RX?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

N.Winterbottom wrote:

I missed this during the last week (perhaps the thread title wasn't interesting enough).

 

But I get the feeling this an XY problem unfolding here:

 

https://en.wikipedia.org/wiki/XY_problem

 

Even after reading all the posts so  far I still could not tell whether this is a problem of SRAM corruption of EEPROM corruption. Or even the conditions under which the corruption occurs.

 

 

It could be.
I solved the eeprom problem by placing an external eeprom.
The real problem (I think) is that although the program works correctly in all its phases, I notice that after a time X some variables are altered making the program no longer working correctly.
I thought of the stack because I do not know what else to think but it could be that my intuition on the stack is completely wrong.

I don't konw.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Some notes about the schematic (Although these are probably not your error)

 

There is a red craoss on U1, the S-1142, pin 3. Could that be a missed connection which makes the voltage regulator turn itself off?

RED LED DL3 is connected to +24Vcc, and before the reverse voltage protection diode D1 / GS1M.

R15, R16, R17 is a really weird combo for RS485, just as the 100 Ohm Series resistors R18 & R19.

Are you familiar with "10 ways to bulletproof RS485"?

RS485 is not a 2 wire connection, but a 3 wire connection. GND is not optional, but mandatory for RELIABLE communication.

https://duckduckgo.com/?q="10+ways+to+bulletproof+RS485"&t=opera&ia=web

I see no ferrite cores / inductors / Chokes or other components for EMI filtering.

Your circuit may get upset by external EMI events, especially with long cables connected.

Sometimes upsets by EMI events can be easily triggered by switching a 12Vhalogen lamp (with real transformer) or Fluorescent ligts (with Inductor as ballast) nearby.

 

After that I had a few looks at your code.

How do you want to maintain such code?

I'm not surprised you get lost and cant find bugs.

I don't like:

1). 300+ lines in a while loop.

2). 7 levels of indentation.

3). 188 character long lines with complicated, but very similar if conditions.

4). No decent use of braces.

5). Magic numbers everywhere.

6). Multiple statements on a single line. I even saw something like:  if (a) { b = c; for( d;e;f) { ....;  ...; ...; }}   // ???

7). In a previous post you said you do not use ADC. Why is there ADC code in your program then?

8). How long does this for loop take to execute?

ISR (USART_RX_vect) {
	if(flag485==0) { buf=0; for(int i=0; i<20;i++) buffer[i]=0; }
    ...

9). I do not see structure in the code. It all looks cobbled together.

  For example: calling a bunch of uart_send() functions in a row, checksum stuff in arbitrary places.

  Instead: Write a communications library with defined RS485 data and buffers.

10). twi.c. Full of magic numbers.

 

I2C is not too difficult to get it almost right, but also notoriously difficult to get perfect.

There are a few infinite loops in your twi / I2C code, such as:

	while ((TWCR & (1<<TWINT)) == 0);

If "something" happens and the condition of the loop is never met, your code hangs.

 

 

11). Header files included from header files.

12). Functions in all captials (usually reserved for #defined macro's): TX485_ONN()

13). Non uniform naming. Also in rs485.c: reset_buffer() init_uart(), USART_putstring(). 

14). Delays in ISR: 

 ISR (USART_TX_vect) {
     mdelay(TX485_OFF_DELAY);

15). 2 different files with void main(void){} ???

16). ...

 

 

Motto:

It is easy to write code that has no obvious errors, but it is very hard to write code that obviously has no errors.

 

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:

Some notes about the schematic (Although these are probably not your error)

 

There is a red craoss on U1, the S-1142, pin 3. Could that be a missed connection which makes the voltage regulator turn itself off?

RED LED DL3 is connected to +24Vcc, and before the reverse voltage protection diode D1 / GS1M.

R15, R16, R17 is a really weird combo for RS485, just as the 100 Ohm Series resistors R18 & R19.

Are you familiar with "10 ways to bulletproof RS485"?

RS485 is not a 2 wire connection, but a 3 wire connection. GND is not optional, but mandatory for RELIABLE communication.

https://duckduckgo.com/?q="10+ways+to+bulletproof+RS485"&t=opera&ia=web

I see no ferrite cores / inductors / Chokes or other components for EMI filtering.

Your circuit may get upset by external EMI events, especially with long cables connected.

Sometimes upsets by EMI events can be easily triggered by switching a 12Vhalogen lamp (with real transformer) or Fluorescent ligts (with Inductor as ballast) nearby.

 

After that I had a few looks at your code.

How do you want to maintain such code?

I'm not surprised you get lost and cant find bugs.

I don't like:

1). 300+ lines in a while loop.

2). 7 levels of indentation.

3). 188 character long lines with complicated, but very similar if conditions.

4). No decent use of braces.

5). Magic numbers everywhere.

6). Multiple statements on a single line. I even saw something like:  if (a) { b = c; for( d;e;f) { ....;  ...; ...; }}   // ???

7). In a previous post you said you do not use ADC. Why is there ADC code in your program then?

8). How long does this for loop take to execute?

ISR (USART_RX_vect) {
	if(flag485==0) { buf=0; for(int i=0; i<20;i++) buffer[i]=0; }
    ...

9). I do not see structure in the code. It all looks cobbled together.

  For example: calling a bunch of uart_send() functions in a row, checksum stuff in arbitrary places.

  Instead: Write a communications library with defined RS485 data and buffers.

10). twi.c. Full of magic numbers.

 

I2C is not too difficult to get it almost right, but also notoriously difficult to get perfect.

There are a few infinite loops in your twi / I2C code, such as:

	while ((TWCR & (1<<TWINT)) == 0);

If "something" happens and the condition of the loop is never met, your code hangs.

 

 

11). Header files included from header files.

12). Functions in all captials (usually reserved for #defined macro's): TX485_ONN()

13). Non uniform naming. Also in rs485.c: reset_buffer() init_uart(), USART_putstring(). 

14). Delays in ISR: 

 ISR (USART_TX_vect) {
     mdelay(TX485_OFF_DELAY);

15). 2 different files with void main(void){} ???

16). ...

 

 

Motto:

It is easy to write code that has no obvious errors, but it is very hard to write code that obviously has no errors.

 

 

 

OMG
Maybe it's better to rewrite it all over again

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

it's this :

unsigned char USART_receive(void){
    uint16_t kk=1000;
    //while(!(UCSR0A & (1<<RXC0)));
    //return UDR0;
    do{
        if (UCSR0A & (1<<RXC0)) return UDR0;
    } while(--kk);
    return 0;

}

But with the new information I will say it's probably some ISR's that block for each other.

I will normally just have one relatively fast timer ISR and then pool the rest!

 

  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

it's this :

unsigned char USART_receive(void){
    uint16_t kk=1000;
    //while(!(UCSR0A & (1<<RXC0)));
    //return UDR0;
    do{
        if (UCSR0A & (1<<RXC0)) return UDR0;
    } while(--kk);
    return 0;

}

But with the new information I will say it's probably some ISR's that block for each other.

I will normally just have one relatively fast timer ISR and then pool the rest!

 

  

The zip file include (but not used in the solution) the file "main_prima_version_bacco.c" The first version of my program and will be deleted.

Here there is second void main(void) referred by Paulvdh.

The subroutine that references is in that file before I wrote the ISR code.

 

In any case, after Paulvdh's beating, I think it's better to cancel everything and start again.

:(

 

I'm sorry to have lost so much time on so many people

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

autsel wrote:
I'm sorry to have lost so much time on so many people
If it was a learning experience, then the time was not lost.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Then the risk of no reduction in severe issue (solve one issue, create another issue)

When the software is functional except for one issue then simply, though maybe not easily, solve the issue.

Some or a lot of effort to solve the issue, or, one may be fortunate (by lint)

Compilers and linters are like peas and carrots.

Some good linters are zero price and low cost; excellent linters are low price, low cost, and an excellent value.

 

"Dare to be naïve." - Buckminster Fuller

Pages