AVRasm2, Debugging, Step By Step, Leads to a Crash

Windows 7, 32
SimulIDE_1.1.0-RC0_Win32, released 20-9-2023 [SimulIDE-R1909_Win32]

I noticed, since long, on the O-scope trace of the generated sinewave a glitch. Lately, I knew it is caused by a bug in the code under test (the attached one here, ‘EarTest_08T10_hiLo.asm’).

So, I tried to debug the code, step by step, starting from its beginning (actually from line 996 or 3090) while checking the values in the MCU variables.

Unfortunately, after stepping several times a crash happens. The number of steps, before a crash, was not the same. And no matter how many times I tried, I couldn’t even reach the entry of the main algorithms (RPTtest:,  jumped from line 3319). Sometimes, the crash is so severe that launching the OS security by CTRL-ALT-DEL took tens of second to appear.

Note:
The attached code here is halted at line 2440 (it is not supposed to output a sinewave). Its purpose is just to save the generated delta bit stream in SRAM into EEPROM. I had to read its entries so that I can also let LTspice plot the generated sinewave. On the LTspice trace the small glitch also appeared (seen clearly at the negative peak).

The circuit in the attachment is not the same as in the picture above.
Is it supposed to be the same?

arcachofo wrote:The circuit in the attachment is not the same as in the picture above.
Is it supposed to be the same?

No, it is not the same.
I added the displayed one just to show the small glitch on the sinewave trace which I am talking about (generated by a bug).

The circuit in the zip file is the circuit related to the actual attached code (version T10). As I used to do, I added it though its O-scope will not display anything. The algorithm in the code that outputs the sinewave will not be reached. This part of the code is not important here while I try to locate the bug in the algorithms that generate the tables in the SRAM space (sine, cosine and delta stream).

If one runs the code without any breakpoint, the only sign that it is running properly is by watching the EEPROM window. The entries of the delta bit stream are saved, byte by byte, in it (starting from address 0x0000). Their number is 194 bytes (=1552 bits of one cycle).

Unfortunately, a crash happens, soon or late (please re-read my previous post) while debugging step by step and before reaching the algorithms of interest.

(I will see if 'SimulIDE_1.0.1-R1386_Win32' can help me find the bug since it usually doesn't crash).

Ok, let's see if I can make it crash...

arcachofo wrote:Ok, let's see if I can make it crash...

Thank you.

I forgot that, in 'SimulIDE_1.0.1-R1386_Win32', saving SRAM wasn’t implemented.

But debugging this code (about Delta Sinewave Synthesis, DDS) is not urgent. I work on this project (besides other non-commercial ones) whenever business slows down and I don’t have a new product to design.

Since I am 74, I try to keep my brain busy in solving new problems with the hope that this slows down its loss of power with age

arcachofo wrote:Ok, let's see if I can make it crash...

If you will have time to test it, please notify me in case you will reach, step by step, the instruction "RJMP RPTtest (line 3319) without having a crash. You may like to start from the instruction (LDI r20, 200 at line 3090 that follows the label NXTfreq:

Perhaps the crashes, on my side, are related to Windows7, 32 only.

If you will have time to test it, please notify me in case you will reach, step by step, the instruction "RJMP RPTtest (line 3319) without having a crash. You may like to start from the instruction (LDI r20, 200 at line 3090 that follows the label NXTfreq:

I can't make it crash and indeed line 3319 is never reached.

Perhaps the crashes, on my side, are related to Windows7, 32 only.

Could be.
Note that Windows can close the program without even asking if it takes too long to respond.
In this case it seems to "freeze" for one or two seconds and then is closed.
This is not a crash, maybe caused by some error, but it is not the same as a crash.
In a crash the program closes inmediately.

So I'm not sure if this is a crash or "it takes too long to respond".

arcachofo wrote:I can't make it crash and indeed line 3319 is never reached.

Very sorry, I picked the wrong "RJMP RPTtest", I forgot that there are more than one of it. The right one is at line 3221 which also returns the cursor to almost the beginning of the code (line 1025).

You are right, the one at line 3319 is not supposed to be reached in this temporary code, updated for test. But the debugger cursor will certainly reach the one at line 3221 (also RJMP RPTtest).

I wonder how many steps (approximately) you did without the program stops responding?

While I am writing you, I re-opened the code and started the debugger. To my big surprise, after 3 steps only, I got immediately what is shown on the attached screenshot.

KerimF wrote:Since I am 74, I try to keep my brain busy in solving new problems with the hope that this slows down its loss of power with age

That's really amazing and respectful .

Very sorry, I picked the wrong "RJMP RPTtest", I forgot that there are more than one of it. The right one is at line 3221 which also returns the cursor to almost the beginning of the code (line 1025).

Thanks, I will have a look.

I wonder how many steps (approximately) you did without the program stops responding?

Hundreds.

arcachofo wrote:

I wonder how many steps (approximately) you did without the program stops responding?

Hundreds.

I don't know what to add after knowing that on your side you kept clicking on the 'Step' icon many hundred times without a problem.

The only difference between our two tests is the OS.

So, I tried now 'SimulIDE-R1677_Win32'. It seems okay in this respect no matter how many steps I executed, one after another.  

But I got the same problem with the next available versions:
SimulIDE-R1709_Win32
SimulIDE-R1741_Win32
SimulIDE-R1751_Win32
SimulIDE-R1861_Win32
SimulIDE-R1894_Win32

Between R1709 and R1677 there are 31 versions. To find out at which version the problem started for windows7, we can follow the procedure by which a non-linear equation is solved (between two limits).

I mean if I will be able to get R1693, (1709+1677)/2, and find out it is okay, the new two limits will be R1709 and R1693, otherwise R1693 and R1677. By repeating this 4 times more, the version that started this problem will be known exactly. I guess this will likely help in figuring out the cause by comparing it with its previous one.

This is just a suggestion. Perhaps you have a better idea in case you are interested.

The problem is that I can't make it crash, so no way to know which version is working or not.

arcachofo wrote:The problem is that I can't make it crash, so no way to know which version is working or not.

If I understood you well, you were able to also test it on a PC (or laptop) whose OS is windows7, 32.