Forum Replies Created
-
AuthorPosts
-
support
KeymasterHi,
The About window would indeed not be shown if the trial had expired, and various other VisualGDB commands and components (e.g. responsible for launching OpenOCD) would not work either.
We usually give a trial extension voucher to help our prospective customers resolve the issues that were not resolved during the normal trial period so that they could decide whether the product works for them. As you have activated the extension voucher on a different machine, it got flagged as redeemed and would not work the second time. If VisualGDB works without any problems on the other machine, most likely either some tools on your home computer are corrupt, or the problems are caused by the expired trial.
support
KeymasterHi,
We usually only issue one trial extension per person and the same trial extension voucher would not activate on multiple machines.
support
KeymasterHi,
We would advise trying to minimize both command lines as long as they still produce different results.
E.g. try removing all .o files from the opencm3 command line and check if you get the same cryptic error or an actual “missing entry point” error. If the message is still cryptic, try replacing the linker script with the normal linker script and if it doesn’t change anything, try removing other options.
support
KeymasterThe RSP file looks OK. As a quick check, could you try creating a new “LEDBlink” project with the same toolchain? If it doesn’t work, please try reinstalling the toolchain.
If it does, please try comparing both RSP files.
support
KeymasterHi,
Thanks for the build log. Unfortunately it looks like an error that happens before the Linker manages to output enough information.
Please try locating the Release\Debug\<ProjectName>.link.rsp file and post its content here (please also attach your <mcu>.props file from the project directory). The file should contain the linker command line and should help us see what could be wrong.
If you see something suspicious in the file, please try running the following command from the project directory:
<full path to arm-eabi-gcc> @Release\Debug\<ProjectName>.link.rsp
If you can reproduce the same error, try removing the suspicious part and run GCC again. If you can successfully pinpoint a part that is causing an error, please edit your settings accordingly.
support
KeymasterHi,
No problem, we can walk you through diagnosing this. Please try setting a breakpoint in ReportFunctionRunTimeToRealtimeWatch() in the profiler framework.
Does the function get invoked? Does the rec.Address expression match the instrumented function address (the least significant bit will be 1 to signify the THUMB code)?
If yes, please try running a regular instrumenting profiler session and switch Live Profiling window to “Diagnostics”. It should show various statistical data (e.g. buffer utilization, samples/second, bytes received). Please attach a screenshot of the diagnostic data here (or simply list all the numbers) so that we can see what is going on.
support
KeymasterHi,
It looks like something in the linker command line is broken. Please try enabling verbose mode via VS Project Properties -> Linker -> Advanced (not the regular VisualGDB verbose mode) and post the entire verbose build output here so that we could help you understand what is going on.
support
KeymasterHi,
We actually have a HAL tutorial here: https://visualgdb.com/tutorials/arm/stm32/uart/hal/
Please try following it instead.
support
KeymasterHi,
Please attach the screenshot of your About window and your debug settings so that we could check the VisualGDB state.
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.
-
AuthorPosts