Nordic NRF52x Devices v15.0.0

[qbinot]

Hello,

I wanted to know if you have a date for the release of the BSP for the new version of Nordic NRF52x Device SDK (v15.0.0).

Thanks & Regards,

Quentin

[support]

Hi,

As it was released very recently, it hasn’t been fully scheduled on our side yet, but 1-2 months could be a reasonable estimate.

[qbinot]

Hello,

It’s been more than one month, do you have a more accurate date now?

Thx.

[support]

Hi,

Sorry, we don’t have a specific deadline for this yet. The new SDK appears to merge the IoT functionality into the mainline SDK, so it might require extra effort on our side to ensure everything works smooth together. We will post an update on the forum once the new release is available though.

[qbinot]

Hello,

The nRF5 SDK for Mesh now requires the nRF5 SDK 15.0.0 to compile.
source : Nordic infocenter

Working with 14.2 is forcing me to keep working with nRF5 SDK for Mesh v1.0.1.

Can you give me a rough estimate of the release date for the new BSP ?

Regards,

Quentin

• This reply was modified 6 years, 4 months ago by qbinot.

[support]

Hi,

It is currently in development, although we did not have a chance to run our full test suite on it yet, so it’s hard to give an accurate estimate. We will likely run the final tests on it in the next 1-2 weeks and depending on the outcome, will either release it or take another 1-2 weeks to polish it up.

[qbinot]

Thanks a lot.

Do you know if it will includes the support for the bluetooth mesh SDK ?

• This reply was modified 6 years, 4 months ago by qbinot.

[support]

Hi,

Sorry, we are not able to 100% confirm it at this point. It will include the sources and examples from the original Nordic SDK, so if the mesh SDK is included in it (and works out-of-the-box), it will likely get included as well. Otherwise it would need to be treated as an external dependency.

[support]

Hi,

Just wanted to share an update that we have a preliminary version of the Nordic BSP based on SDK 15.0 available here: https://sysprogs.com/files/tmp/nrf5x-15.0.vgdbxbsp

As the internal structure of the linker scripts in this SDK has changed, please use this VisualGDB build in order to ensure the correct linker scripts are selected: https://sysprogs.com/files/tmp/VisualGDB-5.4.3.2358.msi

[grindstaffp]

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

[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.

[support]

Hi,

No problem, we will be happy to clarify this here.

The Embedded Frameworks is a convenient shortcut for adding/removing groups of source files (and associated flags) to the project. E.g. if your project references the “FreeRTOS” framework, VisualGDB will automatically add the related sources, include directories and preprocessor macros to the project. Furthermore, if the exact settings change after a BSP update, you will be able to update your project by simply regenerating BSP-related files. The embedded frameworks have a varying degree of accuracy depending on the platform. For platforms that provide structured definition of components they are automatically derived from those definitions. For Nordic devices they are derived from scanning the source folders during our BSP build process and applying a set of simple rules.

The files added via Embedded Frameworks are placed under the “Device-Specific Files” folder in Solution Explorer. This folder is managed by VisualGDB and any changes you make under it (e.g. new files/removed files) will be overwritten next time you regenerate the BSP-specific files. This is by design as it allows updating the project when the list of the sources corresponding to a specific framework changes. All files added to other folders in Solution Explorer (and the “Excluded from Build” flag on the files originating from the frameworks) will be preserved.

Our example projects may indeed include many extra frameworks, as the internal structure of the SDK changed considerably and we have not optimized this yet. The good news is that the link-time garbage collection should take care of this, so the size of the final binary will not be affected.

Thanks for the suggestion with the app templates, we will investigate the possibility of wrapping them as VisualGDB project templates and will include them unless we discover some blocking issues.

[grindstaffp]

This helps a lot. Thank you for the clarification.

[Author]

Posts