[bflannery]

I believe this is the “Refactoring Suggestion” color settings driving this behavior. I am not 100% positive since it has been so long since I fixed that on my install. I can promise the setting is in this menu even if it is not specifically the one I mentioned.

 

 

[bflannery]

Right click on the target you want to load (within the solution explorer) and click “Set as Startup Target” it should be the first option.

The one that is bolded is the current startup target.

• This reply was modified 2 weeks, 2 days ago by bflannery.

[bflannery]

Yes it uses the Advanced CMake project type.

[bflannery]

I made a CMAKE example for you.

https://github.com/pseudotronics/visualgdbexamples/tree/main/DualTargetsExample

[bflannery]

When you create your project you can specify generically  whether you want your program to execute from FLASH or SRAM.

If you want the option to choose simply add another executable target and differentiate them by name. Then you could right click on the one you want to use and press “Set as startup target”. Assuming you are using cmake this can be done just by making two calls to add_bsp_based_executable with different NAME values. You can also specify the linkerscript via LINKER_SCRIPT within that call.

Don’t forget to relocate your vector table in the SRAM version of your executable.

 

• This reply was modified 2 weeks, 4 days ago by bflannery.

[bflannery]

You can suppress the warning by using the variable.

Add this to your CMakeLists.txt

Here we set ignoreMe to the variable thereby using it.

• This reply was modified 5 months, 1 week ago by bflannery.

[bflannery]

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.

[bflannery]

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.

[bflannery]

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.

 

• This reply was modified 11 months, 2 weeks ago by bflannery.

[bflannery]

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.

[bflannery]

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.

 

[bflannery]

This configures without error for me. I didn’t try with the manually cloning.

Side note, I hate wordpress forums.

• This reply was modified 11 months, 3 weeks ago by bflannery.
• This reply was modified 11 months, 3 weeks ago by bflannery.

[bflannery]

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.

[bflannery]

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.

• This reply was modified 11 months, 3 weeks ago by bflannery.

[bflannery]

Thanks! I had no idea that was there.

[Author]

Posts