Forum Replies Created
-
Posts
-
Thanks for the suggestions. I will do more testing and hopefully find a solution. I do not know what could have changed since the last time I successfully ran a debug on this project but I’ve obviously made something unhappy.
I had considered that and placed a breakpoint within the main function prior to any other function calls and was met with the same result, the breakpoint was never reached. The firmware meanwhile was running on the device and live variables were refreshing while running.
After doing a little more testing, debugging works fine in a different project so it seems to be an issue with the project, not necessarily VisualGDB or J-Link.
Thanks. I had previously regenerated the MSBuild-specific files to no avail. No errors were present in the diagnostic log after regenerating the files either. Replacing Intellisense.props in the new toolchain with the one from your toolchain seems to have worked. It still isn’t highlighting some things but its way better than it was.
I have also attempted the above an a separate, new project, with the same results. Thanks for the help!
Please see the attached. After copying the board to the project directory, the custom board root directory is automatically set to $(ProjectDir) and the following log output is generated.
Running CMake: C:\Users\patri\AppData\Local\VisualGDB\CMake\bin\cmake.exe ../../.. -G "Ninja" -DCMAKE_BUILD_TYPE=DEBUG -DCMAKE_MAKE_PROGRAM="C:/Program Files (x86)/Sysprogs/VisualGDB/ninja.exe" -DBOARD=nrf52840dk_nrf52840 -DBOARD_ROOT=H:\Development\VisualGDB\Projects\ncs_test
Including boilerplate (Zephyr base (cached)): H:/Development/SDKs/Nordic/ncs/v1.5.0/zephyr/cmake/app/boilerplate.cmake
-- Application: H:/Development/VisualGDB/Projects/ncs_test
-- Zephyr version: 2.4.99 (H:/Development/SDKs/Nordic/ncs/v1.5.0/zephyr)
-- Found west (found suitable version "0.9.0", minimum required is "0.7.1")
-- Board: nrf52840dk_nrf52840
-- Cache files will be written to: H:/Development/SDKs/Nordic/ncs/v1.5.0/zephyr/.cache
-- Found toolchain: gnuarmemb (H:/Development/Tools/SysGCC/arm-eabi)
-- Found BOARD.dts: H:/Development/VisualGDB/Projects/ncs_test/boards/arm/nrf52840dk_nrf52840/nrf52840dk_nrf52840.dts
-- Found devicetree overlay: H:/Development/VisualGDB/Projects/ncs_test/boards/nrf52840dk_nrf52840.overlay
-- Generated zephyr.dts: H:/Development/VisualGDB/Projects/ncs_test/build/nrf52840dk_nrf52840/Debug/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: H:/Development/VisualGDB/Projects/ncs_test/build/nrf52840dk_nrf52840/Debug/zephyr/include/generated/devicetree_unfixed.h
-- Generated device_extern.h: H:/Development/VisualGDB/Projects/ncs_test/build/nrf52840dk_nrf52840/Debug/zephyr/include/generated/device_extern.h
Parsing H:/Development/VisualGDB/Projects/ncs_test/Kconfig
Loaded configuration 'H:/Development/VisualGDB/Projects/ncs_test/build/nrf52840dk_nrf52840/Debug/zephyr/.config'
No change to configuration in 'H:/Development/VisualGDB/Projects/ncs_test/build/nrf52840dk_nrf52840/Debug/zephyr/.config'
No change to Kconfig header in 'H:/Development/VisualGDB/Projects/ncs_test/build/nrf52840dk_nrf52840/Debug/zephyr/include/generated/autoconf.h'I then add another board to the newly created directory,
H:/Development/VisualGDB/Projects/ncs_test/boards/arm/, see attached boards.zip. This board definition is from the main zephyr repo. I then reload the CMake project but the board is not detected and the log output is the same as above.In order to try to rule things out, I have cleared the cache and build directories, re-launched VS, tried setting the custom board root directory to $(ProjectDir)\boards, all to no avail.
Oddly, at one point i did see the overlay files show up in the log (only once) but the boards were still not added to the boards list. I was only able to have this occur once and spent a fair amount of time trying to re-produce this behavior.
I cannot edit my last reply but I’d like to add that I have added the following to CMakeLists.txt, as outlined in the documentation and still do not see my custom board.
list(APPEND BOARD_ROOT ${CMAKE_CURRENT_SOURCE_DIR})
Once I have a board defined in the local project directory (ProjDir/boards), how do you select it as a platform in the project? It seems like does some detective work when a change is made and finds the original platform device tree but it does not detect what I have added. Thanks for the guidance.
Funny, I was bitten by this too. I knew my support was due for renewal but didn’t realize that after the support period, the key only activates the current version at time of purchase, not the version that had been activated up to that point. Annoying but such is life.
Updating to say that whatever issue I was encountering has been resolved by copying the entire nordic thread and zigbee sdk into the BSP directory. Thank you for providing insight and suggestions on how I might pinpoint a solution.
Good to know. I think Powershell handles the @ differently and I was being too lazy to move to a command prompt.
There must be some subtle differences in some of files that I didn’t copy that allow me to still compile but cause problems during runtime. If my total copy of the nordic sdk files into the BSP does not resolve my issue I will continue down the path of manually running the command as you have suggested.
Thank you for the clarification, I will give that a try later today. I had included the “@” but got errors when running in powershell. I’ll use a standard command prompt for further testing.
My next step after that is probably going to be to replace the files within the BSP with those from the SDK rather than trying to pick and choose just what I needed out of the Zigbee SDK. I am not using a softdevice so that should simplify things but I did notice that the rsp file includes a softdevice directory. Must just be something extra that was included as I have the project set to not include a softdevice.
Don’t see an edit button here but I’d like to clarify that prior to changing the SDK_ROOT path to the Nordic sdk I had that path set to the 15.2 BSP directory.
Adding the Nordic SDK directory as an additional path in the project properties did not appear to have any positive effect when building the project.
