Forum Replies Created
-
AuthorPosts
-
support
KeymasterHi,
You can find out the temporary directory by running “cmd /k echo %tmp%”.
support
KeymasterLooks like the project is missing references to libraries or sources defining a few functions (like airkiss_printfImp). We would advise searching the SDK and your external libraries for definitions of those functions (not just declarations in .h files) and including the corresponding libraries.
November 9, 2017 at 18:12 in reply to: How does the generated bin file burn into the motherboard? #12928support
KeymasterHi,
Unfortunately it’s hard to provide any help without seeing the full context: OpenOCD output, screenshots of your settings, screenshot of your About window to show the current VisualGDB state. Please attach those and we will try to help you.
support
KeymasterThe one from the LIBRARY_NAMES is the correct one (you would also need to remove it from the stm32.xml file as otherwise it will get regenerated).
std::array<> should not be related to compactcpp. Please feel free to post the errors you get and we will help you resolve them.
November 9, 2017 at 06:56 in reply to: How does the generated bin file burn into the motherboard? #12913support
KeymasterHi,
The <offset> files are generated when you debug your program first. You can also use the ESPImageTool.exe from the <toolchain>\esp8266-bsp directory to generate the files or program them via the bootloader.
support
KeymasterHi,
OK, thanks for the log, that explains it. Looks like something is totally wrong with the temporary directory and this breaks the .Net framework. It is surprising it didn’t affect any other programs.
Please try deleting all files in the temporary directory and run chkdsk on the drive containing it.
support
KeymasterOK, sorry about that. We have added another logging layer on top: http://sysprogs.com/files/tmp/VisualGDB-5.3.15.1916.msi (the link will become available in ~10 minutes)
Please open the View->Other Windows->VisualGDB Diagnostics Console window and enable logging before opening VisualGDB Project Properties.
support
KeymasterHi,
Thanks for confirming this. Looks like some internal VisualGDB component is throwing an exception and VisualGDB is not handling it properly. Please try this build:
http://sysprogs.com/files/tmp/VisualGDB-5.3.15.1915.msi
It should display a meaningful error message in this case.
support
KeymasterHi,
It could be that your license upgrade did not get applied properly. Please try re-entering the key via Help->About VisualGDB.
support
KeymasterHi,
Yes, it will be included in the next maintenance release.
support
KeymasterHi,
Thanks for the updated gif. Looks like you don’t have the “Reformat code when ‘}’ is pressed” enabled in the C++ editor settings, so VisualGDB is using an alternate simplified mechanism to layout the brackets.
We have added a workaround to this build that will fix the location of the closing brace: http://sysprogs.com/files/tmp/VisualGDB-5.3.15.1913.msi
support
KeymasterHi,
We would recommend calling the MessageBox() function from your C++ MinGW code at the beginning of the test. This should pause the test displaying the message box. Then you can use Task Manager to locate the PID of the test process and then simply attach to it with VisualGDB (you can also display the PID in the message box itself).
November 8, 2017 at 20:13 in reply to: How does the generated bin file burn into the motherboard? #12896support
KeymasterHi,
The ESP8266 images consist of several non-consequent blocks that need to be programmed at different addresses in the FLASH memory following the “<Project Name>-<Offset>.bin” syntax. The “<project name>.bin” file is generated by the regular objcopy tool that is not aware of the ESP8266 specifics and should be ignored.
support
KeymasterHi,
For a stand-alone project please simply remove “compactcpp” from the list of libraries in the first page of VisualGDB Project properties.
-
AuthorPosts