I am developing embedded C for a TI MSP430 microcontroller, and have spent the last couple days migrating from TI's IDE and proprietary toolchain to a more unix-y workflow of Sublime Text + make + gcc. I'm now trying to set up debugging with WinGDB (Visual Studio with gdb backend) and I've got it mostly working. There's just this one issue with breakpoints which I suspect comes down to a backslash / forwardslash issue, but I don't know how to fix.
I can start debugging without problems, I can step through, view disassembly, etc. But when I try to set a breakpoint in the source file using F9, it shows up as disabled with the hovertext:
The breakpoint will not currently be hit. No source file named d:Documentsccs workspacesmsp430 scratch\013cxmain.c.
Location: main.c, line 13 ('main(void)')
However, I can set and clear working breakpoints with gdb commands in the WinGDB debugger shell, but no little red circles appear next to the source.
The path to main.c is D:\Documents\ccs workspaces\msp430 scratch\vcx\main.c and I discovered that the escape sequence \v corresponds to a vertical tab, or octal \013 in ascii. So I'm guessing the backslashes are screwing something up somewhere (thanks windows).
Any ideas where to look to fix this?
Your error shown is usually generated when your code is optimised by the compiler - such as a = 2; and never used again. But the main problem(s) could be related to your cross toolchain - on this link the cross toolchain implemented in WinGDB is CodeSourcery G++ Lite toolchain for ARM, while your micro, MSP430 is not an ARM device. (there is an MSP432, which is ARM device).
Maybe you can look at this: www. Energia.nu, something similar to Arduino, works with several versions of MSP430.
You are correct that it is a backslash problem, the debug records generated for your files which tell the debugger which file & line resulted in which group of op codes.
You can try modifying your build process to use forward slashes everywhere, since your tool chain is gcc based it should find files named
D:/Documents/ccs workspaces/msp430 scratch/vcx/main.c
but you are also likely to have problems because of spaces in your path, restructure your project so that all spaces are replaced by underscores i.e. D:\Documents\ccs workspaces\msp430 scratch\vcx\main.c gets moved to D:\Documents\ccs_workspaces\msp430_scratch\vcx\main.c etc, spaces in paths can cause all sorts of issues. While it is possible to escape spaces in paths it is better to just avoid them.
I would also suggest taking a look at Code::Blocks - while not as pretty as VS it does a much better job of providing an IDE and debug environment for cross platform and embedded development. It is free, cross platform and open source itself. It interfaces with GDB very well and you can customise the build tool chain that it uses for your project(s). It even comes with presets for GNU GCC for MSP340, as well as many others, so should be very helpful.
Related
Edit : Problem circuvented by generating a Makefile project but I'd still like to know what is going on.
This question echoes my unresolved problem mentioned here (STM32 app not running sometimes, remains in DFU).
I have a custom board STM32L486 based and I am using the built-in DFU mode to upload new firmware over USB using dfu-util on Linux.
Sometimes, for unknown reasons, the app won't start after leaving the DFU mode.
A slight change in code can make it work or break it. (see link above for details).
Examples of changes that can reverse the problem :
Adding / removing a HAL_Delay or a LED Blink
+1 or -1 on an array size
Adding / removing a sprintf format
What seems to work is building the binary with Og optimisation (or using the STLink tool and debug mode).
I have tried to increase the heap and stack (up to 20x the default), it doesn't change anything.
Checking the prepare dead code/data removal options in Atollic seem make build fail more than other times.
What could be causing the issue of the app not starting, not even the init steps ?
How can I track down the culprit flags that may cause this ?
Can this be linked to a memory alignment problem ?
Any ideas / insights / comments on how to check is welcome.
I have been able to reproduce the same issues (from here and my other link) on a Nucleo board.
I tried to generate a Makefile project from CubeMX and the problem does not happen. I guess this is a bug in either the binary generated by Atollic or the compiler/linker settings that the IDE.
Note that my Makefile uses the exact same toolchain as Atollic so this cannot be a toolchain issue.
This issue is hereby circumvented by this, but I'd still like to understand what may happen.
As far as I've tried, this DFU issue and app not rebooting is caused when building from Atollic (TrueStudio).
Generating a Makefile project from CubeMX solved this issue though I still cannot explain why.
I am hoping there are some Windows command-line wizards here. If there are, I am forever in your debt.
I have used R (and related tools) on Linux for years. I do everything in emacs if I can. My fingers are just happier that way.
To ensure my analysis is reproducible, I write a makefile for each report / analysis in a project. I use a combination of R and pandoc to produce reports these days. Once my makefile is written, I simply open a shell and enter:
make -f my_target
And my computer runs my analysis. Easy. On Linux.
I have recently started a job with the government and my computer is running Windows and I no longer have make, except through mingw and neither emacs nor gitbash recognize make. I would like to be able to run make (or something equivalent) from both (or either) emacs / gitbash to run my code in a coherent / sane manner.
Thus my question is this. How can I use make, which is currently ONLY accessible through a msys shell and not connected to either gitbash or emacs or what other tool should I move to so I can continue to "build" my reports in a sane / reproducible manner?
If I am better off learning a new tool, that is fine. If there is some way to run mingw's make from emacs / gitbash that is good too. I am open to suggestions. Most of the tutorials on-line are for Windows programmers moving to Linux. There aren't as many resources for us moving from Linux to Windows (which is understandable).
After much swearing and gnashing of teeth, I finally figured out what I did wrong.
I followed the installation instructions for MinGW, but I made a typo when I altered my user's path. Thus, MinGW was NOT in my path.
Following these instructions work, but it isn't smart enough to fix your typographical errors.
Getting Started
I'm studying "Compilers" and we work on Flex to program.
I create *.lex files (with any editor), convert them into lex.yy.c via flex, and then compile to a.exe using gcc.
Writing lex code in an editor like Notepad/Codeblocks/... is not only hard because everything is just BLACK, but also there is no debugging system.
The gcc compiler does tell about errors, but what i'm looking for is something i can go line by line with the code (in runtime) and see what's going on with the variables. Like the command F10 in Visual Studio.
Does anybody know a suitable program for this? Thanks alot
Concerning hightlighting, using gedit(The default GUI editor on Ubuntu and some other Linux variants) or even vim will provide that for you, you don't have to use plain notepad.
As for the debugging, yes there's what's called the GNU Debugger (aka GDB) which allows you to do typical debugging jobs after you've compiled your code, you can step line by line and examine certain variable values.
Before doing that, first compile your program with the gcc flag -g to add debug symbols to the complied result, then run gdb yourProgramName, this will run GDB and you'll be able, using certain commands, to do whatever debugging tasks you want.
I once wrote a little guide to help people get started with GDB, it might be useful.
first off, I really need to make a 64bit version of glfwdll.a and glfw.dll (so I can hopefully finally succeed in getting the Go glfw bindings to work under Windows ... was a breeeeze under Linux!)
Seems like I now succeeded in compiling 64bit versions of glfwdll.a and glfw.dll using mingw64, MSYS and their make scripts, even though I did get a couple of error messages along the lines of "maincrt entry point not found, using default 0xsomehexnumber instead" or some such. Entry points of course refer to executables, in this case those in the examples directory.
And indeed, most of them don't work! All got built however. The following executables work:
listmodes.exe mtbench.exe mthello.exe and particles.exe -- the latter being the only graphical (3d gfx) example working for me (the former ones just outputting some test infos onto the console window).
Now what's the issue with the other ones? They don't crash, they don't report anything to the console... I run them, they return immediately, silently.
Is my GLFW build broken? How to fix? What's the big difference between the 4 examples that work and the others that don't?
This is a fairly new, vanilla Win7 64bit installation. No crapware, everything up to date, UAC and Themes are off, not a lot of software installed at all, Nvidia GPU driver updated (GPU Caps Viewer and the likes run fine, so OpenGL is there).
I'm not yet allowed to add comments, so I'll post this as an answer.
The issue you're having is due to three separate bug in GLFW. I fixed them today and the fixes will be included in GLFW 2.7.6. Until then, you can use trunk from the GLFW Subversion repository.
To be sure that you really have no DLL-hell issues with the opengl32.dll, glu32.dll, glut32.dll etc., check out the Event Viewer tool and see if there are some warnings or errors for you app.
This is my thought because you are only able to run the mtbench and mthello which have nothing in common with the "real" OpenGL API.
No clue about particles.exe though - maybe GLFW checks for errors internally and call the exit() routine ? Check the %errorlevel% also.
Also take a look here:
http://glfw.svn.sourceforge.net/viewvc/glfw/trunk/examples/pong3d.c?revision=1110&view=markup
There is a GameMenu() function which may exit silently if "!glfwGetWindowParam( GLFW_OPENED )", which obviously means that OpenGL was not initialized.
The same function serves as an exit flag here
http://glfw.svn.sourceforge.net/viewvc/glfw/trunk/examples/wave.c?revision=1110&view=markup
Once again, double-check the DLLs !
I believe that you are experienced not to make "advanced" mistakes in the build process, so there just might be some funny thing happening at the "user level".
And another suggestion:
http://sourceforge.net/projects/glfw/forums/forum/247562/topic/3868944
Some parameters might not work exactly for you.
To "fix" the samples try commenting out the glfwGetWindowParam call.
What is the need/use of 'symbols' in the Microsoft debugger?
I spent some time trying to figure out the debugger a while back and never was able to get it making any sense (I was trying to debug a server hang...). Part of my problem was not having the proper 'symbols'.
What are they? And why would I need them? Aren't I just looking for text?
Are there any better links out there to using it than How to solve Windows system crashes in minutes ?
You need symbols in order to translate addresses into meaningful names. For example, you have locations on your stack at every function call:
0x00003791
0x00004a42
Symbols allows the debugger to map these addresses to methods
0x00003791 myprog!methodnamea
0x00004a42 myprog!methodnameb
When you build a debug version of a program, the compiler emits symbols with the extension .PDB. It also contains line information so you can do source code debugging, etc..
You need to set your symbol search path correctly for the debugger to pick this up. IN the command window you can do
.sympath c:\symbols;c:\temp\symbols
in order to have it search for the .PDB in these directories. It will also look in the same directory that the executable is ran from.
It also might be helpful to use the Microsoft public symbols server so that you can resolve OS binaries such as NTDLL, GDI, etc.. with this path at the beginning:
.sympath SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols;c:\symbols
You will need to create c:\websymbols first.
On the Windows binary architecture, the information needed for debugging (function names, file and line numbers, etc.) aren't present in the binary itself. Rather, they're collected into a PDB file (Program DataBase, file extension .pdb), which the debugger uses to correlate binary instructions with the sorts of information you probably use while debugging.
So in order to debug a server hang, you need the PDB file both for the server application itself, and optionally for the Windows binaries that your server is calling into.
As a general note, my experience with WinDbg is that it was much, much harder to learn how to use compared to GDB, but that it had much greater power once you understood how to use it. (The opposite of the usual case with Windows/Linux tools, interestingly.)
If you just have the binary file, the only info you can typically get is the stack trace, and maybe the binary or IL(in .NET) instructions. Having the symbols lets you actually match that binary/IL instruction up with a corresponding line in the source code. If you have the source code, it also lets you hook up the debugger in Visual Studio and step through the source code.