Forum Replies Created
-
Posts
-
Hi,
No problem. We will try to update the instructions for a newer OpenCV version soon, however due to the amount of other features scheduled before that, it will likely take 4-6 months or more.
Hi,
Sorry, it is still in the queue. ST recently released a few other device families (STM32MP1 and STM32WB) that got prioritized over STM8. We will likely get a better estimate for STM8 in the next 2-3 months.
If the project also doesn’t build directly, it might be missing some configuration entries, or it might be meant for a different version of ESP-IDF (unfortunately, different ESP-IDF versions are not always backward-compatible). Please consider posting on the ESP32 forum to get support for ESP-IDF-specific issues.
Hi,
Does the project also fail at the linking stage when building it directly via command line (outside VisualGDB)?
Hi,
It looks like your ESP-IDF installation is corrupt and is missing some files referenced by the CMake scripts. Please try building the project manually (using idf.py build) and ensure it builds without errors. If the build outside VisualGDB fails as well, please try reinstalling the toolchain/ESP-IDF and if it doesn’t help, try re-creating the project from scratch.
Normally, when VisualGDB rejects a license key that hasn’t been renewed, it will display an error message with a link to this page allowing you to download the latest version compatible with your key, or renewing your key. Please use that page to download the installer for the version compatible with your key.
Hi,
Good to know the installation succeeded. Most likely, the error was caused by some network issues.
You can reinstall CMake via Tools->VisualGDB->Manage VisualGDB Packages or by removing the %LOCALAPPDATA%\VisualGDB\CMake folder.
Thank you for renewing your license.
The error message you reported looks like the project references the system_nrf51.c file that is no longer present in the latest BSP.
Nordic has removed nRF51 support (only leaving out nRF52) in the latest SDK versions, so our BSPs had to follow.
As a workaround, we have released a separate BSP supporting the legacy nRF51 device using the latest BSP version that supports it.The recommended way to proceed with this would be to create a new project for the nRF51 device using MSBuild (GNU Make may not be compatible with the latest Nordic SDKs due to path length limitations) and moving the code to it. It would require additional setup, however omce the code is moved over, you will get much faster building experience than with GNU Make and also better integration with VS property windows.
We can also show you how to patch the existing project definition to have it retargeted to the special nRF51 BSP, however it may not work with GNU Make due to path length limitations.It is hard to say why the VisualGDB project would not call this function as our BSPs contain the code from the original SDKs and do not introduce any changes beyond trivial bugfixes.
That said, it should be relatively easy to narrow it down. Please try replacing the ELF file generated by VisualGDB (<Project directory>\VisualGDB\Debug\<Project Name without Extension>) with the ELF file generated by the NXP IDE. Then select Tools->Options->Projects and Solutions->Build and Run->When Project is out of date -> Ask. Finally, start a new debug session and don’t rebuild the project. This will launch the ELF file produced by the NXP IDE using the VisualGDB’s debugging logic. If this results in a usable USB device, the problem happens at the build stage.
In that case, please try setting a breakpoint on the code responsible for calling the Connect() method in both projects and try comparing the behavior. If debugging the original ELF file under VisualGDB doesn’t work, please check if using the “Program and start without debugging” works for the original executable and for VisualGDB-based executable.
As we have mentioned above, the errors are shown because the toolchain you installed got corrupt (some libraries got replaced with incompatible versions).
We can help you configure it correctly if you could let us know the exact steps you are performing (including the URLs of the toolchain, SD card image) and a description of the exact choices you pick in the wizard (if possible, with screenshots). Then we can check your configuration for common errors and suggest what could be causing it.
Please also try running “lsb_release -a” on the Beaglebone and share the output you receive.
Hi,
No problem, we can help you track this down, however we would need some clarification from you first.
Is the project that works built with the GCC compiler under a different IDE, or is it using a completely different compiler (e.g. IAR)?
If it using gcc, we would advise using Embedded Memory Explorer to compare the 2 ELF files (see this tutorial). Specifically, check if there are some symbols that are only present in one project, but not the other one, and also check the addresses of main() and some global variables (they will be different, but should be located in the same memory region for both ELF files). Also check if the project contains board-specific code for clock setup (e.g. PLL, clock divider, etc) and ensure both projects use the same settings.
Sorry, unfortunately the log you posted is missing the link command line that would be shown at the beginning. Please attach the entire log, not just the bottom part of it (you don’t need to enable verbose logging on VS level for Make projects, as they handle verbosity on a separate level).
For GNU Make, the default log settings should already contain the necessary command lines.
Please try rebuilding the project and check the output for the line containing liblog4cplus.a. Simply post that line here and we will help you understand it.
Hi,
Thanks for the clarification. It looks like you have installed the new toolchain and then resynchronized its sysroot with an incompatible SD card image, thus, breaking the build process.
Please note that each toolchain is compatible with a specific version of the target system (see this page for a full list) and synchronizing it with a different target system version would lead to the problems you described.
If you are no longer sure which SD card image you are using, please try downloading the latest one listed on our toolchains page and writing it to your SD card (this will replace the previous card contents). Then, install a toolchain that is compatible with that image. This should allow creating Qt projects correctly. Once you can confirm that the new projects work, you can install the necessary libraries (e.g. QtSerial) via apt-get and resynchronize the sysroot to make those libraries available to the cross-toolchain.
Unfortunately, as you have cropped the project properties window screenshot, it’s hard to see which build subsystem you are using and give specific advice.
Generally, the use of absolute paths vs. “-l” syntax should not affect the link outcome, as long as the libraries are found. Either way, the undefined reference to `log4cplus::Logger::~Logger()’ message means that the ~Logger() symbol is either missing, or the library providing it is specified outside the -start-group/-end-group pair (see this page for a discussion about linker groups).
Please try enabling the verbose build logs and double-check that the the library paths end up between the -start-group and -end-group arguments. If not, please let us know the build system you are using (Make/CMake/QMake/MSBuild) and we will help you find the relevant settings.
If the library is specified as expected, please check that the one of the source files in the library actually defines the ~Logger() symbol. You can read more about symbol declarations and definitions here: https://visualgdb.com/tutorials/tips/externc/
