Forum Replies Created
-
AuthorPosts
-
support
KeymasterAre you using the Clang IntelliSense engine? When we tried reproducing the problem, pressing ctrl-space showed the suggestion list with one entry, but did not result in ‘stop_realtime_timeraltime_timer’.
support
KeymasterHi,
We would recommend first ensuring that you can add the library to a basic “Hello, World” project by following one of our OpenCV tutorials. Once that works, simply take a note of the include paths and library names added to the Hello, World project and add them manually to the Qt project via VisualGDB Project Properties. This will let your Qt project use OpenCV the same way as the Hello, World project does.
April 20, 2016 at 18:12 in reply to: Error Messages with Keil MDK-ARM Compiler not parsed correctly #8017support
KeymasterHi,
It should not normally require any extra steps. Can you double-check that the XML file got saved to the c:\program files(x86)\sysprogs\VisualGDB? Perhaps the UAC folder redirection got it saved into a different place accidentally?
support
KeymasterHi,
You can set per-user variables and simply reference them in the path mappings.
support
KeymasterHi,
The problem is that this behavior is defined inside the gdb itself and the only way to override it would be via modifying the gdb sources. As there are many different platforms where gdb runs, maintaining such a modified version would be unsustainable.
VisualGDB does not show getters by design – to avoid accidentally invoking some function that may crash your program. If you want to get more usable display of your variables and fields, you can create .natvis files defining how to extract meaningful information from complex objects.
support
KeymasterHi,
Thanks for the video. The problem might be related to the one of the changes you made. To double-check that please try running exactly the code we provided, without disabling the watchdog and with exactly the same period.
If you can confirm that it does not work, the problem is in the hardware. If it starts working after removing watchdog-related code, the problem is related to the watchdog.
Regarding os_printf(), the gdb stub does support that. VisualGDB currently displays the output from the stub in the GDB Session window together with the other gdb output (you need to select “All GDB interaction”). We will support displaying it separately in the next major release of VisualGDB.
support
KeymasterHi,
This comes from the gdb’s implementation of running functions in Watch expressions. It runs them ‘as is’ and does not check for things like null pointers.
Evaluating functions in-place is a powerful debugging feature, but it needs to be used carefully as there is no 100% safe way to run arbitrary functions in native code without potentially crashing the program.
support
KeymasterHi,
Normally VisualGDB should be able to parse the GCC output and show it in the Errors window. Are you using a cross-compiler or compiling directly on the Linux machine?
support
KeymasterThe link shows “the video is private”. Did you manage to get the code we sent working without any modifications?
support
KeymasterHi,
Perhaps something is wrong with the power supply of your board and it’s constantly resetting itself? We have tried the following project with the gdbstub and were able to step over a breakpoint on the s_Tick++ line:
static os_timer_t s_Timer; int s_Tick = 0; void TimerFunction(void *arg) { s_Tick++; asm("nop"); } int user_init() { #ifdef ESP8266_GDBSTUB gdbstub_init(); #endif gpio_init(); os_timer_setfn(&s_Timer, TimerFunction, NULL); os_timer_arm(&s_Timer, 300, 1); return 0; }
Can you verify that you get the same behavior with this reduced program? If yes, please try getting an Olimex board. The ESP8266 chips are not very reliable, so it could easily be a strange hardware problem.
support
KeymasterHi,
Yes, that’s the easiest workaround. VisualGDB indeed assumes that same host name means the same remote machine and adding extra entries to hosts should to the trick.
support
KeymasterHi,
Please try the following:
- Change the firmware to turn on the LED, disable interrupts and wait indefinitely
- Try programming the firmware using JTAG. If it does not start, unplug the board and plug it back. Does the LED actually turn on after you restart the board?
support
KeymasterThanks for the suggestion. We are actually considering similar functionality (auto-import of sources from CMake files), but it’s hard to say currently what extent of it will be included in v5.2 as there are still some unresolved things left.
support
KeymasterHi,
It’s hard to suggest anything without seeing the outcome of the tests suggested above. We have ordered a bunch of ESP-03s and will make a tutorial once they arrive.
If you need a trial extension, simply use the contact form on our website and mention this thread and we will extend your trial.
support
KeymasterOK, first of all, we did test all the projects on the Olimex board, so it is probably some small configuration issue with ESP-03. In order to resolve it, you need to localize the problem. It can be in one of the following places:
- FLASH programming never happens
- FLASH programming succeeds, but starting the program fails
- The built images are wrong
- The program fails to start with JTAG attached
To figure this out, please try the following:
- Change the firmware to turn on the LED, disable interrupts and wait indefinitely
- Try programming the firmware. If it does not start, unplug the board and plug it back. Does the LED turn on?
- If yes, try debugging it with no FLASH programming. Does this help? If yes, try changing the reset mode in VisualGDB Project Properties.
- If the programming does not turn on the LED, try programming the same .bin images (not the .ELF file) using esptool. Does this work? If yes, something breaks programming and the full GDB log might provide answers.
If you encounter any difficulties at any point, please feel free to share the details and we will try to help you.
-
AuthorPosts