[grindstaffp]

Hello,

You understand correctly. I have two projects, one provided by Nordic that works when compiled in SES (and now tested using GCC via command line) and one that I have put together in VGDB that uses the exact same code from the Nordic example that compiles but does not function the same.

I have spent the day making the following changes in an attempt to get things working:

1. Compared compiler and linker settings between SES and VGDB. Any compiler and linker flags found in SES were added to the VGDB project settings. –> Project compiles as before. Program runs but hangs.
2. Went through the VGDB project and pruned all unnecessary source files that had been included by VGDB. I did not expect this to help much but worth a try.
3. Nordic example project has a Makefile that I used to further test different compiler and linker flags in VGDB. –> Project compiles as before. Program runs but hangs.
4. Compiled Nordic example with aforementioned Makefile. Program functions as expected.
5. Copied Makefile into VGDB project directory and made minor modifications to Makefile for file paths. –> Program compiles fine, hangs during runtime.
   1. Renamed project EmbeddedProject3.c to main.c and recompiled (from command line). Same result as above.
   2. Makefile can be seen here.

I find it very strange that using the Makefile from the Nordic example on the VGDB files has the same result as compiling directly from within Visual Studio. I did not add or subtract anything from the SRC_FILES or INC_FOLDERS sections. I simply updated the SDK, PROJ_DIR, and LINKER_SCRIPT paths. According to the output, there were no problems during compilation or linking.

I attempted to use the .rsp files as mentioned in your response however amr-eabi-gcc did not particularly care for the “EmbeddedProject3.link.rsp” that I gave it.

arm-eabi-gcc .\EmbeddedProject3.link.rsp
h:/development/tools/sysgcc/arm-eabi/bin/../lib/gcc/arm-eabi/7.2.0/../../../../arm-eabi/bin/ld.exe:.\EmbeddedProject3.link.rsp: file format not recognized; treating as linker script
h:/development/tools/sysgcc/arm-eabi/bin/../lib/gcc/arm-eabi/7.2.0/../../../../arm-eabi/bin/ld.exe:.\EmbeddedProject3.link.rsp:1: syntax error
collect2.exe: error: ld returned 1 exit status

I also copied the contents of the .rsp file to the console and was met with a wall of errors of files not being found and unrecognized flags. I spent a while going down this path and eventually gave up and I was unsuccessful at ever getting anything but errors.

<hr />

During the writing of this post I modified the SDK_ROOT path in the aforementioned Makefile to point to the untouched Nordic SDK and recompiled. Now the program is working as expected. Following this revelation, I have compared the Nordic Thread/Zigbee SDK folder with the VisualGDB BSP and moved a few more folders over. Unfortunately whatever I am missing was not fixed by simply adding a few more files to the BSP directory. I have updated the project on github and added the Makefile used that resulted in a successful compile. Is there any way someone can take a look and help me find the missing piece? I feel like I am getting close but I am missing the last piece of the puzzle.

Thanks for the support.

[grindstaffp]

I noticed this issue yesterday while working on a project. It seems that opening a project from the most recently used list (right click VS icon and select project) causes the issue in my case. Closing the project and starting Visual Studio then opening a project resolves the “not an embedded project” problem.

[grindstaffp]

Apologies for coming across so critically. Obviously with the number of platforms that you guys support there will be some delay between the SDK release and you guys being able to pull it into visualgdb.

Fortunately it wasn’t too difficult this time (who knows what changes Nordic will make that break the bsp tool in the future) to have a usable, but not polished 15.2 bsp. While it isn’t supported and doesn’t pull the examples through, it works with a bit of tweaking. But tweaking is the name of the game I guess since Nordic doesn’t support visualgdb out of the box, however much we wish they did.

[grindstaffp]

While not perfect, running SDK 15.2 through VisualGDB’s BSP Tool yielded a workable BSP which I have been using since 15.2 was released. Unfortunately, the officially tested and released BSP from sysprogs will be coming not long before the next official SDK (rumored over on devzone).

[grindstaffp]

In case anyone is interested in using the Thread and Zigbee SDK with VisualGDB it turns outs to be fairly simple. The main SDK and Thread and Zigbee SDK are very similar. The basic steps are below. If there turns out to be any interest I could probably throw together a more specific tutorial.

1. Copy the thread, zigbee, and 802.15.4 directories to the corresponding BSP directories. There are a couple of other additional directories that may need to be copied as well.
2. Copy the thread and zigbee linker scripts into the BSP directory (Optional, just replace contents of local project linker script).
3. Include the thread/zigbee directories in your project as needed.
4. Include the appropriate libraries by name (ie. zboss.a)

At this point you should be able to copy one of the examples into your project and it should compile (once you satisfy any missing dependencies). You will need to use the example’s sdk_config.h, not the one included in your project.

[grindstaffp]

Thanks for the information.

[grindstaffp]

This helps a lot. Thank you for the clarification.

[grindstaffp]

Having used the sneak BSP for a few days now I wonder if I can ask a couple of questions regarding the behavior of the embedded framework options and available examples. I realize this BSP is still being developed so perhaps things have changed.

I noticed this evening that when I would change anything in the embedded frameworks window that header and source files previously added to the solution would disappear and revert back to what may be the Original state of whatever example was used. For example, after adding nrfx_timer.h/c to the project by right clicking in the solutions explorer and adding an existing item, if a setting was changed by checking timer (or any other parameter) in embedded frameworks, nrfx_timer would be removed from solutions explorer. I assume this is not the intended behavior and thought I’d mention it.

I am sure there is documentation somewhere that explains the intended use of the embedded frameworks window but I cannot seem to figure out exactly what it’s role is in the development lifecycle here. Clicking various parameters under nrf components or modules does seem to do something but I did not necessarily notice that the source files for a given selection are added to the project in project explorer. Would someone be able to explain the purpose of making framework selections here rather than adding files through solution explorer?

Another behavior that I found somewhat strange with this BSP was the files included by default with examples. When opening the basic Blinky example, legacy peripheral modules, radio source files, and others are included by default. With SDK 15 being as different as it is, I tend to guess that more default includes than necessary might have been added to the examples to ensure everything works out of the box. I could be wrong here but it was somewhat shocking to see so many different resources included in some of these examples. This is more of an observation with the understanding that we currently just have a pre-release BSP and that the final release will likely change.

Finally, if they haven’t been included already as templates for us to base a project on, I would like to request that the simple app_template and ble_app_templates be made available as a starting point (I hope I have the names right, I do not have them in front of me).

Thanks for taking a look.

[grindstaffp]

The linked debug package fixed the issue. Thanks.

[grindstaffp]

Awesome! Have been waiting for this to become available before I jumped on buying a license. Thanks!

[Author]

Posts