support

Forum Replies Created

Viewing 15 posts - 6,706 through 6,720 (of 7,846 total)
  • Author
    Posts
  • in reply to: Building STemWin_HelloWorld on STM32F7 Discovery board #7218
    support
    Keymaster

    Hi,

    Looks great, thanks for sharing this!

    in reply to: Cross-compiling Qt Embedded 5.5 for Raspberry Pi 2 #7217
    support
    Keymaster

    Hi All,

    Normally you don’t need to install any new packages on your Pi as long as your ld.so.conf is set correctly and the /opt/vc directory is synchronized.

    We have added troubleshooting instructions to the step 16 of the tutorial: http://visualgdb.com/tutorials/raspberry/qt/embedded/

    Let us know if you run into further problems.

    in reply to: Openocd jtag driver problem #7211
    support
    Keymaster

    Hi,

    OK, then the problem must be elsewhere. Please double-check your FLASH type setting (dio/qio/etc) in VisualGDB Project Properties.

    Please also try manually programming the <project>-0x40000.bin and <project>-0x00000.bin files from the Debug directory using the bootloader and esptool.py.

    If the LED blinks in that case, something goes wrong with programming the FLASH over JTAG. If the LED does not blink (but blinks when you are using the GDB stub), something about the images is corrupt and the next step would be to compare the images produced when using the OpenOCD debug method with the images produced from the same ELF file when using the gdb stub.

    in reply to: Openocd jtag driver problem #7208
    support
    Keymaster

    Hi,

    If your program still contains the gdb stub, the stub will stop at the beginning of the program and wait for gdb to connect. Perhaps this is causing the behavior you are describing. This can be easily checked by pressing the “Break in” button in Visual Studio and examining the call stack.

    You can disable this by defining GDBSTUB_BREAK_ON_INIT=0 in VisualGDB Project Properties -> Makefile Settings, but this will prevent you from debugging your program from the very beginning using the stub, as the program will quickly advance beyond user_init() before VisualGDB manages to connect to it.

    in reply to: Using the QuadSPI on STM32F7 Discovery #7207
    support
    Keymaster

    Hi,

    Please use the USBDriverTool to restore the original ST-Link driver. It also looks like the newest OpenOCD works correctly with the stock driver, so you don’t need to install the WinUSB-based one anymore.

    in reply to: Error 'Importing Specs' #7201
    support
    Keymaster

    Hi,

    Sorry, I did not fully understand you. Could you attach some screenshots with setting PATH and building it, showing the PATH setting that breaks and the PATH setting that works?

    The transfer to Raspberry Pi happens when you start debugging, so if you get errors during build, they are not related to transfer errors.

    in reply to: Suggestion required – Affordable JTAG for ESP8266 OCD #7200
    support
    Keymaster

    Hi,

    Almost all inexpensive JTAG adapters are based on the FT2232 chip, so they are pretty much all the same, just differently packaged. Any Olimex one or something like FlySwatter from TinCanTools will do.

    in reply to: User Variables in Pre-processor macros #7199
    support
    Keymaster

    Hi,

    The logic of automatically detecting that would be probably too complex and error-prone given a fairly simple workaround. We could add a button to trigger retesting manually if that helps.

    in reply to: Using the QuadSPI on STM32F7 Discovery #7198
    support
    Keymaster

    Hi,

    Sorry, we don’t support that yet. We would recommend using the ST-Link utility. We will also monitor the popularity of QSPI-related searches and add a tutorial on it if the topic becomes popular.

    in reply to: BeagleBone-Debian Qt5 Toolchain #7197
    support
    Keymaster

    Hi,

    The ui_MainWindow.h file is generated during build. So if you build the project and re-open it, IntelliSense should it pick it. If this does not happen, please check whether the file actually exists and whether its directory got added to the IntelliSense directories in VisualGDB Project Properties.

    in reply to: Openocd jtag driver problem #7196
    support
    Keymaster

    Hi,

    What exactly is happening to the device? Is the LED blinking? Did the FLASH programming progress window appear? What is the contents of the GDB Session window (if you enable “All commands” view)?

    Does changing reset mode in VisualGDB Project Properties help? Have you tried connecting the reset to pin 3 on your JTAG20 as described in the tutorial?

    in reply to: Openocd jtag driver problem #7192
    support
    Keymaster

    Hi,

    If this is a reprogrammed ARM-USB-OCD-H or another device, please use the ST-Util to restore the original VID/PID and specify the OpenOCD script accordingly. Please also ensure that you have a WinUSB-based driver installed. You can install it manually using USBDriverTool.

    in reply to: Wiping MCU memory #7191
    support
    Keymaster

    Hi,

    If you are using OpenOCD, you can try running the ‘mon flash erase_address’ command in the GDB Session window:

    mon flash erase_address pad <start address> <FLASH size>
    in reply to: Error 'Importing Specs' #7184
    support
    Keymaster

    Hi,

    This is strange. What happens if you open command-line prompt in your project directory and run the following commands?

    set PATH=C:\Pi\Toolchain\bin;%PATH%
    make

    Do you get the same error message? Is the .elf file created? What if you run “make all” or “make DEBUG/<ELF FILE NAME>.elf”?

    in reply to: #ifdef __cplusplus -> Where is this defined? #7183
    support
    Keymaster

    Hi,

    VisualGDB uses a different build mechanism, so forcing the C++ files to be treated as C would involve adding “-x c” to CXXFLAGS. However, we would recommend simply renaming your .cpp file to a .c file to avoid further problems.

Viewing 15 posts - 6,706 through 6,720 (of 7,846 total)