Forum Replies Created
-
Posts
-
Hi,
Thanks for reporting this and sorry for the inconvenience. We have double-checked the installer file and resolved the problem. You should be able to install it as usual now.
Hi,
No problem. With the reset sequence, you might be able to reset it by first triggering a bootloader reset (same as when programming FLASH), and then immediately issuing an “exit bootloader” command or programming an empty image without erasing. Checking the bootloader sources might help find the exact commands or suggest a better idea.
With hardware debugging, if the board has the JTAG or SWD pins exposed, the Olimex debugger should work.
We have also added an option to control the vertical scrollbar in the console to this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2430.msi (under Tools->Options->VisualGDB->General->GUI). The default colors unfortunately would be trickier, so we will try to add an option for them next time we redesign the terminal settings logic, but we won’t be able to add this option in v5.4.
Hi,
No problem and thanks for reporting this. Looks like one of the components in our toolchain was using files from an earlier build. We have fixed it and published an updated toolchain. Please update to the R12 toolchain via VisualGDB Package Manager.
Hi,
Most likely your cross-toolchain is out-of-sync with the target SD card image. Please ensure you are using a compatible toolchain/SD image combo (see this page for supported versions).
Hi,
No problem and sorry we couldn’t offer further help with this. That said, if you discover that mbed itself works on a different target, but doesn’t work under VisualGDB, feel free to share the details here and we will help you get it to work with VisualGDB.
Hi,
Strange. The MSBuild-based projects use a different mechanism for locating the toolchain property sheets, although it should be automatically synchronized to the mechanism used for GNU Make.
Could you please share your %LOCALAPPDATA%\VisualGDB\FindToolchain.props file and the .vcxproj file so we could check for possible causes of this?
Hi,
Sorry about that, looks like the previous build was missing the Arduino builder component. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2428.msi
Hi,
This is something managed by mbed itself and not directly by VisualGDB, so we would advise checking mbed documentation and perhaps creating a thread at the mbed forum.
Hi,
Thanks for your feedback. The “build and Flash” issue might be caused by a timing error somewhere in the FLASHing logic. If you could share the output from an unsuccessful FLASHing operation, we might be able to tell more. We could also add a delay setting between the completion of the build and FLASHing.
With samples, thanks for the suggestion. We will consider searching more directories for samples in one of the next VisualGDB versions, although we won’t change this logic now due to our release schedule.
You can change the colors of the Arduino terminal via the corresponding page of VisualGDB Project Properties (you need to enable it first). We have added an option to change the inactive color to this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2427.msi
We have also double-checked the behavior for failed FLASHing, however could not reproduce any problems. Could you please share the internal output from such a session? Perhaps the underlying tool still exits with code 0 despite the error?
With terminal reset sequence, this is specific to your Arduino board. Please check its schematics and Arduino forums/documentation. Most likely there is a sequence of events (e.g. setting/clearing signals like DTR) that lead to a reset. Once you find that sequence, let us know and we can help you configure VisualGDB to use it.
Hi,
Please try restarting Visual Studio. If it doesn’t help, please let us know how did you import the toolchain (automatic installation via VisualGDB, manual import, copied the XML file, etc.) and whether the toolchain is shown in the VisualGDB Package Manager or the toolchain selector in the wizard.
Hi,
Unfortunately we were never able to reproduce this on our side, or hear any more details about this, so it’s hard to suggest anything beyond the existing advice.
We might be able to see what is going on and suggest a fix if you could try extracting the valgrind command lines from the diagnostics console, running them manually on Raspberry Pi and sharing the results.
Let us know if you need more details.
Hi,
Please try running the build command shown in the log file manually and check the output for error messages. Most likely your project either contains constructs incompatible with the newer IDF, or some files cached from the previous build are interfering with the build. In the latter case, please try doing a clean build (Build->Rebuild All). This should remove any cached files.
Hi,
No problem. This message means that the ProfilerRTOS_FreeRTOS.c file from the profiler framework was either not built, or the USE_FREERTOS macro was not set. Please ensure that the file is include in your target’s file list and try adding USE_FREERTOS to the preprocessor macro list.
Hi,
No problem. The ESP32 register definitions are not 100% precise, as they are computed from parsing the ESP-IDF header files. We have updated the code responsible for parsing them to handle some of the previously missing registers (see the R11 toolchain release here).
However, other registers (e.g. SPI, UART) that use non-trivial rules for computing the base addresses are still not included. As a workaround, please consider editing the <SysGCC>\esp32\esp-bsp\registers.xml file manually or hardcoding the rules for the missing register groups in our header file parser.
