I am using cubeIDE version 1.8.0 and NucleoF746ZG microcontroller for my project. I have made the codes and when I compile and run they work properly without errors and warnings. But the problem is that when I try to debug, It doesn't work. I mean the debug code uploads to the board but no cursor shows up at the breakpoints. I have tried to make some breakpoints and hault the program at them but no cursor comes to them.
I have opened a trace control tab and it says "Tracing is not supported". I don't know why that happens. The only thing that I know is that after installing the software, It didn't recognized my st-link. It was fixed after replacing the libusb-1.0.dll to a newer version of it. That was the thing that I have changed. But I don't think that it will affect since compiling and running works properly.
If anyone has encountered this issue or if you have any clues about a cause for this matter, please let me know. And request me if you need any more details from my side. I have attached two screenshots for reference.
Thanks and Kind Regards...
Screnshot1
Screenshot2
Related
I have recently installed gdb from Mysys2. However it isn't functioning properly. When I try to use gdb for debugging I am having this error as seen in the pic. I am not able to debug, and inputting is also not possible. Please help me out rectifying this problem.
Every time I try to run my code, I am having this error: "Csc.exe" exited with code - 255.
I removed and re-installed Visual Studio 2015 and it did not help.
Does csc.exe succeed with different code?
It is possible that you’ve found a bug in the compiler that causes it to crash when trying to compile your particular program. To see if this is the case, create a new “Console App” project with Visual Studio (VS) and see if the default app in the template compiles and runs. If that works, then your code might be triggering a csc.exe crash. If that doesn’t work, your VS install might be completely broken in which case I would recommend uninstalling and reinstalling VS (but you already tried that). If you cannot get VS to run even simple programs on your computer, you’ll need to try to track down why it is crashing and see if it is something you can manually fix. If your system is messed up enough and it is not worth tracking a fix down, you might consider reinstalling Windows (using the “Reset” feature).
Another thing to try is running your code on another computer with VS installed. That can help determine if the issue is your code triggering a compiler error versus your computer being messed up.
If csc.exe only crashes for your particular code, then that is a bug in csc.exe. If there is an issue with your code, csc.exe should generate a nice error explaining the issue with your code instead of crashing.
It is also possible that your code is valid but a compiler bug causes csc.exe to crash. An example of this (with VS 2017 and csharp7) is roslyn#19182. If this is the case, you might try using the VS feedback (frowny face/feedback button in the upper right hand corner) feature to report the issue so that the VS developers know about it. Also, you might be able to poke your code around until suddenly VS starts running successfully. If this is the issue, it might be hard to guess why csc.exe is crashing, but, if you can, try to isolate the issue. For example, if csc.exe was running fine before you made some changes to your code, look at the changes you made and see if undoing them results in csc.exe running successfully again. Then try to make a new, minimal repro which causes csc.exe to crash and send that as feedback using VS’s feedback mechanism or by reporting a bug against the roslyn project. You might also ask a new question here about why that particular code causes csc.exe to crash. With particular code, people might be able to guess why csc.exe can’t handle it and suggest workarounds to use while waiting for the VS team to release a fix.
As it is, your question does not have enough information to guess why csc.exe was crashing for you. Hopefully this answer provides some guidance on what steps you should take if you ever end up in such a situation.
I believe this is similar to the thread: Canon SDK 2.11 on OSX
However the solution there did not work for me. I'm perplexed because I'm not sure how to figure out what has changed. I had some working software, did not work on it over the holiday and now when I open it up to work it fails. Not only my software but the demo app included with the SDK, which I have never changed and indeed used to work just fine.
I have tried with two different cameras (5DmII and 5DmIII) with the same result.
when I try and run the application, the camera is recognized but, as it attempts to open a session it receives a EXC_BAD_ACCESS signal. In each program it happens when a call is made to EdsOpenSession() with this message...
*** -[NSConcreteData release]: message sent to deallocated instance 0x8157af0
Interestingly, when I tried to use the EOS Utility that would crash also. So I updated and now that works great. I followed the suggestion in the above thread and copied the EDSDK.framework from the working bundle to my program and recompiled but I get the same results.
I'm trying to figure out how to contact Canon to get some information but they don't make it easy to get help so I'm appealing to the one group I know is responsive.
The only thing I can think is that sometime over the holiday I updated some critical library without knowing it.
Has anyone else run into and been able to solve this?
I'm running OS X 10.7.5, xcode 4.1, and EDSDK 2.11.3
Solved this. It did turn out to be the same solution as the mentioned link. However, what I was missing was that I needed to also copy the new EDSDK.framework into /Library/Frameworks not just have it in my source directory. This may be because I don't have everything setup correctly in XCode.
I am trying to debug a few C++ applications with KDevelop 4.0.1(on KDE 4.4.5 and gdb 7.0.1) on Debian 6.0.6. Irrespective of what part of the code I break into, the debugger detaches automatically after stepping through a few instructions. I didn't find anything on this topic on any forums. I tried a few things below.
Debugging using gdb on shell works perfectly fine.
Tried debugging multiple applications, but the issue is seen.
Reinstalling KDevelop did not help.
Am I missing some configuration that could cause this behavior?
(I am new to kdevelop)
Thanks for any help.
My guess is that is related to pretty printing of an uninitialized variable.
Lots of fixes have been applied to KDevelop and gdb, you should consider updating to a more recent version.
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.