You need to log in to create posts and topics.

Debugger not stepping properly with Arduino

PreviousPage 2 of 2

Glad you were able to fetch it. Sorry about the hassle. Thank you for this suggestion. As soon as I have an opportunity to validate this I am going to and share the results. I appreciate the quick response.

Sorry it took me so long to get back to this. It has been a busy week. I just re-tested after renaming the assembly file to .asm. I see no noticeable difference in behaviour. Here is what the contents of the directory look like, for reference. What is now .asm used to be .S.

I recorded another video, which may be helpful, after renaming the file as you had recommended. Please, have a look at this. I am sorry, I could not upload here due to the restriction. https://drive.google.com/file/d/1iB8X6hzGZzx73xF_Fh8mq7DcpFToAICp/view?usp=sharing.

-rw-r--r-- 1 szaydel staff 34962 Nov  3 10:22 m328Pdef.inc
-rw-r--r-- 1 szaydel staff   113 Nov 10 09:50 simulide_assembly1.asm
-rw-r--r-- 1 szaydel staff    67 Nov 10 09:52 simulide_assembly1.asm.hex
-rw-r--r-- 1 szaydel staff    13 Nov 10 09:52 simulide_assembly1.asm.eep.hex
-rw-r--r-- 1 szaydel staff   167 Nov 10 09:52 simulide_assembly1.asm.obj
-rw-r--r-- 1 szaydel staff   268 Nov 10 10:29 simulide_assembly1.asm.cfg
-rw-r--r-- 1 szaydel staff   684 Nov 10 10:29 simulide_assembly1.sim1
-rw-r--r-- 1 szaydel staff    67 Nov 17 10:01 simulide_assembly1.hex
-rw-r--r-- 1 szaydel staff    13 Nov 17 10:01 simulide_assembly1.eep.hex
-rw-r--r-- 1 szaydel staff 44213 Nov 17 10:01 simulide_assembly1.lst
-rw-r--r-- 1 szaydel staff   169 Nov 17 10:01 simulide_assembly1.obj

 

There is something weird there.
Maybe you have files from previous compilations?

What happens if you delete all .hex .obj and .lst files and compile?

I went ahead and did as you had suggested. Removed all files other than simulide_assembly1.sim1, simulide_assembly1.asm, and m328Pdef.inc. I recompiled, uploaded the hex file and same exact behaviour. I cannot imagine that this is somehow a result of running on an ARM mac?

No idea what is the problem.
And I can't replicate your results.
For me, extension .s does not work because it generates file.s.hex instead of file.hex.
Avra expects extension .asm (at least in my system) and it works normally.

Understood. I am using .asm now with same results. If you can think of something else I am happy to try. I am assuming that there are no other settings that I need to configure for this. My basic assumption is that when I start the debug session I should be able to single step through the code and properly jump incrementing variables in the loop. I expect all this to work without any further configuration. Please let me know if my assumptions are correct.

Thank you for trying to debug this with me.

Regards, Sam.

Don't need any configuration, just be sure that everything is correct: MCU frequency is ok, reset pin is deactivated and so on.

For what I see the compilation is ok, and the source is mapped correctly.
Also remember you mentioned that the program is actually running.

Maybe is just the GUI not updating?
You can try to run 1 step and then resize the Editor window to force an update, If the arrow moves then it is an update problem.

BTW, I'm assuming you are using the last version, isn't it?

Thank you for the feedback. Latest version, yes. I will check to see if maybe this is in fact a GUI issue.

Just wanted to confirm that this issue, whatever it is, isn't an artifact of the GUI doing something funky. I did confirm that I get two clicks on the "Step" button before it grays out. However, only the first click actually does something. The following click does not appear to do anything. On the first step, I do see the little arrow on the left side of the editor advance to first actual line of code. On second click of the "Step" button I see the register change, which is what the line is meant to do. I cannot make any more steps at that point, because the buttons gray out.

I understand that we kind of hit a wall with this debugging. I will keep messing with it and will let you know if I uncover anything.

Thanks for all the help.

arcachofo has reacted to this post.
arcachofo

I wanted to share another observation. When I click the "Run To Breakpoint" button, I can see that while the triangle in the gutter of the text editor box does not appear to advance past line 5, the value in R18 is 0x2 , which means the debugger reached the breakpoint at line 12 and stopped there. I seemingly cannot continue past this point, i.e. the debugger stops and won't resume again, but I make it to the breakpoint. I cannot reach the breakpoint if I single step however. One thing that is very consistent is that I get to make two clicks, which translates to two steps. In the first step I reach line 5, but it is not executed. In the second step line 5 is executed and I can see the MCU monitor reporting 0xAB in register R16. I don't think this helps much, but I just want to report all the observations that I am making. Attached screenshot should hopefully help to clarify what I am describing.

Uploaded files:
PreviousPage 2 of 2