Open minkir014 opened 2 years ago
Hi, I think probably all the problems you describe are because even with the optimizations off the compiler does not always generate exactly the code you write. The only way to be sure is to look at the listing file which shows your code together with the generated assembly code, but basically it should be this. You can find more on this in the avr_debug.pdf in /doc folder in this repository, see Problem: The program is not jumping at some line or is jumping somewhere I don’t want it to… section.
One thing to try is using -Og optimization option instead of the -O0. The -O0 is set in the platform.local.txt
file (see the lines compiler.c.flags=-c -g -O0 and compiler.cpp.flags=-c -g -O0) .
It may help a little but still don't expect that the program will stop at any line.
I'll try to explain what I see in your code: main.cpp - this is not my code but the main code of Arduino framework. You can see that it is calling your loop() function. If you try to Step into on the loop() line, you should get inside your loop.
The variable Y is never used, A is never read, so I suspect the compiler just does not generate any code for them and there is no code to place the breakpoint at. Even if the variables are used, the compiler may still replace them with constants or use CPU registers to hold them and again there will be no code. Try using volatile on them (volatile int a = 5;
) to force the compiler to generate the code.
It is similar with the dehk() function - the return value is never used so calling it has no effect on the program and the compiler is just not generating it. The compilers are really smart :)
I'd say these are things we have to live with. What is harder to overcome are the limitations of the default "RAM breakpoints" mode of the debugger. In a larger real-world project you will probably need to switch to "Flash breakpoints". Please look for it in the pdf.
BTW I started using PlatformIO extension in the VS Code instead of the Arduino plugin described in the article on codeproject. It is much easier to configure various options (such as the optimization level) and also to use the debugger.
Regards
i'm currently to debug a function to see why it gives me a negative numbers in arduino
and the only thing that helped is to use the volatile keyword, anything else just skipped the line.
and cause the debug to disconnect.
i don't think i'l be able to use the debugger in a real project i keep having to give a "clean setup" cause i can never know what's causing to disconnect or worse going with errors during debug ../../../../gcc/libgcc/config/avr/lib1funcs.S: No such file or directory.
void loop() { delay(200); //breakpoint(); volatile long int i = HebrewCalendarElapsedDays(5783);// HebrewCalendarElapsedDays(5783); }
` long int HebrewCalendarElapsedDays(int year) { long int MonthsElapsed = (235 * ((year - 1) / 19)) // Months in complete cycles so far.
About skipping a line or jumping to some unexpected location I would just repeat what I wrote in the above answer.
If the debugger is disconnecting, it is a different problem. It could be that the program crashes somehow (divide by zero, for example) - if it happens with just this program. If it happens with all programs, it could be some problem with the serial communication with the boards. There were some problems in communication on some versions of Windows with some versions of the USB to serial chip on Arduino boards. It helped to use "TCP to serial" proxy in case the communication was not stable. Please see the pdf,manual "Using TCP-to-Serial proxy (Windows only)", page 93, and/or search for "proxy" in the document to see if this could be the reason in your case. But if the serial connection was unstable in this way it was usually impossible to debug at all, the connection was dropped right after the program started, maybe after few steps. So I am not sure this is the problem.
The "No such file or directory." on some C library code is yet another different problem, I think. It could happen if you try to step into some standard C function, for which the debugger cannot find the source code. This is more about configuring the GDB debugger on your PC than about the avr debugger in Arduino. If it does not cause any trouble other than the message, you can just ignore it.
It is true that this software-only debugger has many limitations. You could also try this project, which uses hardware debug line: https://github.com/felias-fogg/dw-link.
I hope this helps.
yea, i've been considering on using an additioanl arduino (i have an uno) for debugging)
Hi, I am beginning to learn to use your debugger but it is going uneasy for me. I am using Arduino UNO Rev3. I have somethings I couldn't understand. I don't know if I am doing something wrong.
First, I have had a problem at the start as it said that there was no
avr-gdb
installed. But, I searched and found thatSysGCC
makesAVR
version of C/C++ Compiler tools and it includedavr-gdb.
I then began to debug, after I had followed the instructions and turned
g++
andgcc
optimization off. Yet, my debugger skips some lines. Here are examples of What I am encountering.I first have my
app.ino
as followsWhen I upload the code and run the debugger, instead of stopping at
digitalWrite(13, OUTPUT)
it stops in 'main.cpp` of your code.Knowing that it doesn't stop in general at any
digitalWrite()
because it stops at the seconddigitalWrite()
correctly. I have also experimented with removing and commenting some statements, it seems like the debugger doesn't stop at the first few statements.More weird is that it doesn't stop at any variable definition/initialization and skips even some operations as far as I have tested. Because at the first image, I included a breakpoint at
a++
but When I run, this is what I get. It seems that it also doesn't stop in functions.The breakpoint at
a++
disappeared and the breakpoint in the function greyed out.This project was my way to try the debugger as I am trying to use it to implement a bit large project and it doesn't involve using Arduino Code as much as The use of Algorithms. So, I am trying to understand if I am doing something wrong or is that some sort of limitation of UART-based debugging?
Thanks for your help a lot.