Forum Replies Created
-
Posts
-
I would probably just add a post build action for the release target to run “strip –strip-debug” on the produced executable.
or
You could pass “-Wl,–strip-debug” into the linker for your release target.
I would examine the call stack first.
Then you should also ensure that DEBUG_DEFAULT_INTERRUPT_HANDLERS is set to 1 if you are using the startup file that visualgdb generates. Likely there is an interrupt you are not handling. You can also write some code for your hard fault handler to dump the cpu registers to see what the source of the hard fault was.
I would like to second having this be a setting. I would like to disable:
- If the string you typed exactly matches the beginning of a suggestion, (e.g. you typed “print” and it found “printf”), typing any non-identifier character (space, opening bracket, comma, etc) will trigger a completion and will insert the character you typed.
Honestly this functionality gets in the way more than it speeds up my programming. I would much rather have autocomplete only complete what I am typing when I press tab.
Here I am trying to create a local variable named, alarm. The sensible thing for me to do would be to type space to continue this line of code or end it with semicolon if it was simply a definition.
However, that would autocomplete to a macro. Instead I need to hit escape and I don’t like reaching for that key because it interrupts my typing flow/train of thought.
It is hard to say what your problem is without seeing some code.
As for your question “Could I have done something in my main app to set some register that prevents my app from running outside of the debugger?”
Possibly. There have been occasions where I’ve had hardfaults appear out what at the time seemed like thin air. After resetting your board you can connect a debugger to the target and examine the call stack.
Debug >> Attach to Running Embedded Firmware (assuming it is running and is halted somewhere, your editor should jump to that spot, and pause the execution)
Have you made any modifications to your linkerscript intentional or otherwise? You could be placing your program in SRAM.
You can override the variable by setting it in your CMakeLists.txt file.
Otherwise, you should just be able to modify your CMakeCache.txt to point the variables at the correct git executable.
This is located under {ProjectDir}/build/VisualGDB/{Configuration}/CMakeCache.txt
Not sure why it is finding the wrong git.exe to begin with though. It may have something to do with where you added git.exe in your environment variables. If visual studio wasn’t running under your credentials it may not see a user variable.
This post on stack overflow seems to describe a solution to your problem.
https://stackoverflow.com/a/43995834
And if clearing the cache doesn’t work perhaps you can try setting the variable manually.
If you want to use git within CMake on windows you need to make sure git is runnable from from your ps/cmd environment.
You will probably find difficult to run the arm-linux-gnueabihf git executable on your windows machine.
If you add git to your PATH and restart visual studio I believe this issue will go away. (also remove the find_git)
Test by running “git version” from your command prompt.
You could try building the toolchain yourself with the large address aware flag.
I am curious how big your binary is when your build doesn’t fail. I ran into this issue when I had external memory sections set to load when they shouldn’t have been.
Understood. I figured that would be the case. I just thought I would let you know that the way it fails is not a good experience and impacts the other aspects of debugging. I will avoid expanding that section myself moving forward, but I imagine I won’t be the last person to run into this.
What happens if you wrap it in a __cplusplus guard? Looks like it is treating that source as a c file.
