Forum Replies Created
-
Posts
-
Hi,
It looks like the anti-tampering logic of VisualKernel has engaged and is preventing parts of it from being initialized correctly.
Please make sure you do not change any registry keys related to VisualKernel and do not modify its components.
Most likely, you are using an incompatible combination of an Arduino core and a debug method. Please make sure you follow our AVR debugging tutorial to configure debugging of your board.
If it doesn’t work, please share the screenshots of all the wizard pages with the choices you make while creating the project, and also the screenshots of all the settings pages where you change any settings so that we could check for common errors.
Thanks, this looks like gdb fails to initialize.
Please try running the gdb executable shown in the log manually from the command prompt window and see if it’s being blocked by your antivirus or any other component.
You can also try deleting the entire C:\Users\Carlos\Documents\ArduinoData folder and re-creating the project from scratch. This will re-install all the packages and tools, including the up-to-date version of avr-gdb.
Thanks for reporting this.
We have investigated the issue and found the root cause. The Nordic nRF5x SDK 16.0 indeed does not contain linker scripts for the following MCU/softdevice combinations:
- nRF52810/S113
- nRF52811/S113
- nRF52832/S113
Our BSP generation tool incorrectly substituted the missing linker scripts with the S113 scripts for nRF52833 and other devices, that indeed contained invalid memory sizes.
We have updated our BSP generation tool to skip the missing scripts for now. We have also updated it to generate the correct memory size for the nosoftdev option.
As the issue only affects the device/softdevice combinations that are not directly supported by the Nordic SDK, we will not release an update to the current Nordic BSP, however we will take it into account in the next BSP release based on the 17.0 SDK (expected in a couple of months from now).
You should be able to use the S113 softdevice with nRF52832 by patching the linker script manually, however we generally advise using the device/softdevice combinations that are directly covered by the Nordic SDK examples, as they should behave more reliably.
No problem. The link was posted in our first reply in this thread.
Either way, here it is again: https://visualgdb.com/support/logsubmit
Hi,
The path mapping looks correct now. If the problem persists, please send us a screenshot of the problem along with a gdb log and we will help you understand what is going on.
Hi,
Sorry, this doesn’t look like a gdb log. Please make sure you follow the instructions from the page linked in our previous reply and send us the gdb log described there and not any other logs.
No problem, you can configure the path mapping between GDB and VS as shown here: https://visualgdb.com/documentation/pathmapping/
Hi,
No problem. Please try creating a gdb log as shown here and attach it to the thread so that we could see what is going on.
Thanks, the steps you described should normally work, so most likely the problem is caused by some project-specific setting.
Normally, SysprogsInstrumentingProfiler_QueryAndResetPerformanceCounter would be defined in the InstrumentingProfiler.cpp file inside the profiler framework (unless you are using Nordic nRF5x devices that do not have a DWT register and require a timer-based implementation in ProfilerDriver_Nrf5x.cpp).
Searching all files included in the project for SysprogsInstrumentingProfiler_QueryAndResetPerformanceCounter should explain why it’s not being linked properly.
Hi,
Yes, please try using the “Add Configuration” button in VisualGDB Project Properties instead. It will make sure all VisualGDB-specific files and settings are properly created.
Normally it should be added automatically. It’s hard to say why it wasn’t, but if you can reproduce the problem reliably and share the steps with us, we will be happy to fix it.
Hi,
Sorry, we do not have any USB examples for the EFM32 chips. Please consider asking on StackOverflow or EFM32 forums to get further pointers.
No problem and thanks for the update. Just a quick clarification from our side: normally the ID/Version variables would be set inside the project file and the _ROOT and _DIR variables would be computed inside the %LOCALAPPDATA%\VisualGDB\FindXXX.props files that are managed by VisualGDB. So deploying these files to the build machine should get the variables working automatically.
You can find more details on this in our TFS tutorials here: https://visualgdb.com/w/tutorials/tag/tfs/
