I2C + TIMER0_OVF_vect can create continuous resets (R977 @ WIN10)

When TWI and Timer0 are used from AVR core, it seems that the core "resets" continuously, once a signal gets received.

I have two outputs included: ok signal in main-loop (PORTB0) and (re)start signal ahead of the main loop (PORTB1).
The (re)start signal should there be only once, but appears continuously after receiving a signal

OK Situation


Resetting Situation after pushing start button



The problem appears in R927 and younger until the R977.
The version R872 and older don't show the problem.

There is also another minor bug: When triggering the righthand logic analyzer on Ch4 (SDA), once triggered (=pushing start) the ok-signal (yellow one) disappears.

I could not test this issue.

In the attachments there is sources for only 1 firmware which looks the slave one.
And the Master.hex file does not looks to be using TWI module.

strange... when I download the zip file, I can directly reproduce the relevant output on the logic analyzer with the hex-files, before and after pushing the "start button".

I thought, that the code of the master is not as important.
...and... it was "recklessly borrowed" unchanged from a students project, in order to lower my effort    ...

I cleaned up the master code technically and also "cleaned up" the personal details.

strange... when I download the zip file, I can directly reproduce the relevant output on the logic analyzer with the hex-files, before and after pushing the "start button".

I think it's loading other hex files, not the ones in the zip file.

I cleaned up the master code technically and also "cleaned up" the personal details.

Thanks!

strange... when I download the zip file, I can directly reproduce the relevant output on the logic analyzer with the hex-files, before and after pushing the "start button".

Sorry... I didn't understand how it works.
I was not clicking on the "Start" button...

I didn't realize until i saw the source code.

no worries...

Indeed there is no bug here, it is just doing what the code says.
And that is basically:
- Any interrupt not implemented will restart the program.

Code:

0:   jmp   0x68
4:   jmp   0x7c
8:   jmp   0x7c
c:   jmp   0x7c
10:   jmp   0x7c
14:   jmp   0x7c
18:   jmp   0x7c
1c:   jmp   0x7c
20:   jmp   0x7c
24:   jmp   0x7c
28:   jmp   0x7c
2c:   jmp   0x7c
30:   jmp   0x7c
34:   jmp   0x7c
38:   jmp   0x7c
3c:   jmp   0x7c
40:   jmp   0x80
44:   jmp   0x7c
48:   jmp   0x7c
4c:   jmp   0x7c
50:   jmp   0x7c
54:   jmp   0x7c
58:   jmp   0x7c
5c:   jmp   0x7c
60:   jmp   0x7c
64:   jmp   0x7c
68:   eor   r1, r1
...
...
7c:   jmp   0   


Well... this looks weird to me, in my opinion there should be a "reti" instead.

I haven't get again into this, but maybe my conclusions are wrong.

I feel very tired these days, and while debugging this issue, I was not even sure of what I have in front of my eyes.

Your feedback is right and also consistent with the info about it on the internet. So, I learned another thing of the AVR compiler - and feel sorry for raising the issue..

I will have a look into this again. I tried to extract the issue from some student project, where it was embedded deep in more code. I need to have a look, wether I stumbled over my own feed by the "extraction".
I'm not sure, if your explanation is the end of the story, or if there is an other bug I saw.

Currently I have to prepare some other stuff, but I hope I can give more infos in some days: either to close this here or to specify it more correctly.

Thanks for the feedback.

I didn't know avr gcc was doing this, it looks more convenient to just add "reti" as default.
And I don't remember to had this problem before, so it was a surprise...

and feel sorry for raising the issue..

You absolutely shouldn't.
It's allways better to report, and there is always something to learn.

In adition it totally looked like a genuine bug because it didn't happen in previous versions.
I guess it started to happen after solving TWI interrupt errors...

At least we know that addind the ISR routine solves the restart problem.
So the author of that firmware can keep working in it.
Btw, TWI interrupt seems to be continuous, so it keeps triggering until the flag is cleared by sotfware.