[support]

Hi,

Thanks, we have fixed the search functionality. It should find forum posts now.

[support]

Hi,

Thanks for the screenshot. The setup looks correct, but the “JTAG scan chain interrogation failed” error suggests something is wrong with the wiring.

As mentioned in the previous posts, ESP8266 devices could be tough from the reliability point of view, so we would recommend starting with a board that we have successfully tested and then moving back to NodeMCU once you can confirm that the rest of the setup works. Otherwise it’s hard to diagnose what’s going on as ESP8266 does not report the internal errors in a very understandable way.

[support]

Hi,

You are using the correct toolchain. xtensa-lx-106 is the CPU architecture for ESP8266 (like ARM would be for STM32). The ESP8266 toolchain can be installed either in esp8266 folder or the xtensa-lx-106-elf folder depending on which installer you use.

Regarding the wiring, from our experience with ESP8266 and ESP32 the chip has great features, but it’s extremely flimsy. Same setup may work on one board and randomly break on another one; sometimes a board works for some time and then randomly dies; sometimes doing a full erase helps, sometimes it does not.

It also looks like the Olimex boards are more reliable than the original ESP-XX modules and NodeMCU. So our advice would be to get it working on the Olimex one to rule out problems with JTAG cable, JTAG debugger and software bugs and then try the same setup on NodeMCU. We understand this is a big inconvenience, but unfortunately the ESP8266/ESP32 devices are still very fresh and not very reliable.

[support]

Hi,

The easiest way to do that would be to use the Quick Debug feature. Alternatively you can add the ‘VisualGDB’ platform to an existing project via VS Configuration Manager and manually set properties like ‘Toolchain’ and ‘VisualGDB Settings’ file via VS project properties. You can copy the .vgdbsettings file from an existing VisualGDB project as well as the other settings.

[support]

Hi,

The “Error: JTAG scan chain interrogation failed” error usually indicates wiring problems. Please double-check your connections. If this does not help, please try using exactly the same hardware and layout as shown in one of our tutorials.

[support]

Hi,

Sorry, the screenshot did not get pasted properly. Could you try uploading it to imgur or any other image hosting?

[support]

Hi,

We have double-checked the sources of CppUTest and the solution is actually much simpler.

Please comment the ‘return’ line after the following line in SysprogsTestHooks.cpp:

fprintf(stderr, "SYSPROGS_TEST_REPORTING_PIPE not set. Cannot report test status!\n");

This will let the tests proceed even when the VisualGDB-specific reporting mechanism is not set, so you won’t need any special command line.

[support]

Hi,

SysTick handler should be handled normally. Perhaps some sort of memory corruption is taking place? Do you see the SysTick listed in the live profiling window? Does temporarily disabling interrupts get it over the place where it usually gets corrupt?

Regarding “check all” and “uncheck all”, we have added those buttons in our development branch and will include them in the next maintenance build.

[support]

Hi,

Thanks for the update log. Now it looks like VisualGDB is getting the expression type correctly, but it looks like there are too many expressions checked in one session, so it’s hard to understand what is broken.

Please try creating a local variable of the list type, clear the GDB Session window and add that variable to watch. Then please attach a screenshot of the watch window and the corresponding gdb log. Please avoid evaluating that variable before you reset the log, as VisualGDB will then cache its type and not re-query it, so we will not be able to see what is going on.

[support]

Hi,

Looks like you are using the toolchain designed for barebone embedded devices on a Linux-based board.

Please try using one of the Linux-based toolchains (e.g. Raspberry Pi).

[support]

Hi,

Thanks, we have managed to reproduce this and it simply looks like the FLASH erase takes longer than the default timeout of 5 seconds.

Increasing the timeout to 10 seconds solved the problem in our setup. We will update the default timeout in the next toolchain release. As a workaround, please increase it manually by adding the following element to your .vgdbsettings file inside the DebugMethodProperties/Entries element:

        <KeyValue>
          <Key>com.sysprogs.esp32.openocd.alg_timeout</Key>
          <Value>10000</Value>
        </KeyValue>

[support]

Hi,

Thanks for the log, however it does not include the -var-create command that is essential to understanding why VisualGDB does not treat this variable as a list.

The output should normally look like this:

-var-create --frame 0 --thread 1 - * "l"
^done,name="var1",numchild="1",value="{...}",type="std::__cxx11::list<int, std::allocator<int> >",thread-id="1",has_more="0"
ptype/mt std::__cxx11::list<int, std::allocator<int> >
&"ptype/mt std::__cxx11::list<int, std::allocator<int> >\n"
type = class std::__cxx11::list<int, std::allocator<int> > [with _Tp = int, _Alloc = std::allocator<int>] : protected std::__cxx11::_List_base<_Tp, _Alloc> {
}
OK
-var-info-path-expression "var1"
^done,path_expr="l"
-data-evaluate-expression --frame 0 --thread 1 "\(void\ \*\)&\(\(l\)\._M_impl\._M_node\)"
^done,value="0x7fffffffea10"

Please also ensure you are using the latest VisualGDB 5.2 as the STL container visualization was significantly optimized in this version.

[support]

Hi,

If you are running Jenkins on Linux, you would need to use the unmodified version of CppUTest. The exact steps to use it are different on different Linux distros, so searching online for <your Linux distro> cpputest should normally get relevant instructions.

If this helps, we could also add a command-line switch that will disable VisualGDB-specific test reporting so that you could run your tests on Linux by adding something like “-standalone” to the command line. Let us know if you would prefer this.

[support]

Hi,

Looks like you are trying to view a dump related to a shared library. In that case you would need some extra steps to ensure the symbols are read properly:

1. Copy the main executable that corresponds to the dump on your Windows machine and specify it in the Quick Debug settings instead of the .so file.
2. Copy the .so file with symbols and any other relevant .so files to a directory on the Windows machine (e.g. c:\symbols) and run “set solib-search-path c:/symbols” via the ‘enter additional startup commands’ option so that GDB can locate the libraries.

You can check that the symbols for .so files have been loaded by running the “info shared” command via the GDB Session window. If they are not loaded, please double-check the listed libraries, symbol files and the search path.

The “cannot read memory” error is not related to symbol handling. Most likely gdb tries to some heuristics while unwinding the stack (or Visual Studio tries to follow a pointer) and reaches an area of memory that is not included in the dump file. This is normal and should not interfere with the rest of the functionality.

[support]

Hi,

The errors shown in the OpenOCD log you attached should not interfere with programming.

Most likely your board is slightly different from the regular nRF52 boards and the code needs to be adjusted somehow. We would recommend first trying it with the nRF52-DK board as we have explicitly tested VisualGDB-generated projects with it. Once you get it to work, you can try checking your board manufacturer’s website for instructions on configuring projects for that board and perhaps board-specific examples.

[Author]

Posts