[support]

Hi,

Sorry for the delayed reply. We have double-checked the compatibility between VisualGDB 5.2 and VisualKernel 2.1r2 and could not reproduce this behavior.

It also looks like the package version shown in your log [VisualGDB.VSPackage.VisualGDBPackage, VisualGDB, Version=5.1.7.0] is from v5.1, not v5.2. Perhaps the uninstallation/reinstallation did not complete correctly? Please double-check the version of the “C:\Program Files (x86)\Sysprogs\VisualGDB\VisualGDB.exe” file.

If it it 5.2, but ActivityLog still mentions 5.1, please try completely uninstalling VisualGDB and installing it back. You can also explicitly run devenv.exe /setup with all other VS instances closed to force VS to update its package cache.

[support]

Hi,

It looks like your firmware does not get properly programmed into the FLASH. The default SystemInit() function for a LPC1549 project normally looks like this:

(gdb) x/10i SystemInit
   0x1f0 <SystemInit>:  push    {r7, lr}
   0x1f2 <SystemInit+2>:        add     r7, sp, #0
   0x1f4 <SystemInit+4>:        bl      0x774 <Chip_SystemInit>
   0x1f8 <SystemInit+8>:        nop
   0x1fa <SystemInit+10>:       pop     {r7, pc}
   0x1fc <SystemCoreClockUpdate>:       push    {r7, lr}
   0x1fe <SystemCoreClockUpdate+2>:     add     r7, sp, #0
   0x200 <SystemCoreClockUpdate+4>:     bl      0x4c8 <Chip_Clock_GetSystemClockRate>
   0x204 <SystemCoreClockUpdate+8>:     mov     r2, r0
   0x206 <SystemCoreClockUpdate+10>:    ldr     r3, [pc, #8]    ; (0x210 <SystemCoreClockUpdate+20>)

Please try running the “x/10i SystemInit” command from the GDB Session window to see if the disassembly instructions there look correct (you can run arm-eabi-gdb.exe <your ELF file> and run the same command there without connecting to a target to see the function contents recorded in the ELF file).

Please note that for NXP LPC devices we recommend using Segger J-Link instead of OpenOCD as OpenOCD support is not very reliable. You can also try experimenting with the FLASH parameters in the OpenOCD script files to get FLASH programming to work.

[support]

Hi,

Thanks, indeed the internal list structure has changed in one of the last toolchain releases. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.16.1455.msi

[support]

Hi,

Thanks for the offer, but it looks like it could be much simpler to track it down with a few more steps.

Please try stepping up to the SystemInit() call and then switch to the Disassembly view and try stepping instruction-by-instruction until you see the faulty one. The exception could be caused by one of the following:

1. Invalid stack pointer. The crash would happen after a “push” instruction. You can check this by adding the following expression to the Watch window and then changing its value:
   *((unsigned *)($sp – 4))
   If the value can be changed correctly, the $sp address is valid. If it stays 0 despite changing it via the “value” column, the $sp value is incorrect.
2. If the crash happens immediately after a “bx” instruction, some of the code could have been placed to a wrong address. Please double-check the address validity.
3. If the crash happens after an instruction that accesses memory, please check whether the corresponding pointer is valid and where did its value come from. It could be an indication of a memory corruption error.

[support]

Hi,

Sorry for the confusion here. The variables like ${PROJECT_SOURCE_DIR}  are expanded by CMake, but only during build. To optimize debugging performance, VisualGDB only expands VisualGDB-controlled variables (like $(SourceDir)) in various VisualGDB-related settings. The “$(SourceDir)/Debug/src/libraspicam.so.0.1” path actually needs to be specified manually (please see the step 26 in the tutorial).

You can deploy the library to /usr/lib by changing the “deployment path” setting on the Debug Settings page of the library project. Please note that this won’t work unless you explicitly grant write permissions to /usr/lib to the current Linux user.

A simpler alternative could be to add the deployment folder to the LD_LIBRARY_PATH variable (see the Debug Settings page of VisualGDB Project Properties of the debugged executable).

[support]

Hi,

Looks like you are referring to an embedded project then. You can create other configurations for this type of projects as long as you use the VisualGDB Project Properties dialog for it instead of the regular VS Configuration Manager. If this does not work, let us know the details and we will help.

[support]

Hi,

VisualGDB does support other configurations, but the underlying build system (e.g. CMake) may impose certain limitations. Which project type/build system are you using?

[support]

Hi,

This could be some sort of a conflict between VisualGDB and VisualKernel. Are you using the latest VisualKernel 2.1r2? If not, please try checking if updating it solves the problem.

[support]

Hi,

We will rebuild the OpenOCD from the latest Github sources in the next month, so if the fix is already there, it will be included.

We usually don’t add support for new devices to OpenOCD ourselves as the OpenOCD maintainers usually do that anyway, so if the support is not there yet, patching it manually (it’s usually straight-forward) could be the easiest way to get it to work.

[support]

Hi,

Looks like the _estack used in the latest log is valid: when VisualGDB writes a random value just before the end of the stack, it is read back correctly:

[   25566 ms] ^done,name=”var1″,numchild=”0″,value=”0x39ddb05d”,type=”void *”,has_more=”0″
[   25567 ms] -var-assign “var1″ 0x4847923d
[   25631 ms] ^done,value=”0x4847923d”
[   25631 ms] -data-evaluate-expression “\*\(\(void\ \*\*\)0x2003ffc\)”
[   25648 ms] ^done,value=”0x4847923d”

Hence the problem must be caused by something else. Could you try setting a breakpoint on the Reset_Handler() function and stepping through it to see which part causes the exception?

Unfortunately we would not be able to reproduce it on our side, as we don’t have an LPC1549  board.

[support]

Hi,

Looks like libmysqlcppconn.so is corrupt or taken from an incompatible system. Please double-check the file and try reinstalling the package that provides it.

[support]

Hi,

No, that should be sufficient. VisualGDB will warn that the stub is not included and the debugging won’t work, but if you ignore the warning, the programming will still succeed.

You can also use the ESPImageTool.exe from the toolchain directory to program the binary directly.

[support]

Hi,

If you are using the GDB stub, it will wait for the debugger to connect after each restart, i.e. the device won’t start without a debugger until you disable the gdb stub.

[support]

Hi,

Please check the ActivityLog.xml file mentioned in the error message for detailed error records. This should explain why VisualGDB is not initializing.

Either way, please try reinstalling VisualGDB as it would repair any corrupt files.

[support]

Hi,

Unfortunately the ESP8266/ESP32 devices are not very reliable and often behave unpredictably. We could quickly check if your firmware works with our Olimex ESP8266-EVB to see if the problem is in the board or in the firmware. Feel free to archive your project (with the binaries) and upload it to a file hosting so that we could check it.

[Author]

Posts