• State Verified Answer
  • Replies 6 replies
  • Subscribers 62 subscribers
  • Views 1769 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 129218
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

SDK Migration - nrf_log back to experimental in SDK14.2

Roman

I'm using SDK 12.2 with Softdevice S132 V3.0. I try now the migration to the most resent SDK 14.2 with its Softdevice, because it seams there were several bugs fixed in between.

Despite of the migration guides, the migration is quite a hard work and now i realized that the ble_advertising.c (and other regular files) includes the nrf_log.h which has been moved to a folder "experimental_log".

Is the nrf_log experimental or just in a missleading named folder?

Other regular library files include experimental library files too... Is SDK 14.2 really stable?

Further, I'm not sure at what version several bugs have been introduced and if it is really necessary to migrate to latest version or if 12.3 would be stable enough (Softdevice, BLE and Flash Write on nRF52832)?

Parents
  • 0

    Hi,

    Between SDK 13 and 14 the logger was significantly refactored and extended. It had some stability issues, but most of them are fixed in 14.2. It is also not properly documented yet. Especially with regards to some of the new modules that it is using, like ring buffers and memory handling. That is why we moved it back into experimental.

  • 0 in reply to MartinBL

    Hi Martin,

    Thanks for your answer. I think, there is no reason to go to 14.x unless I need one of the new features. So far, I only have to decide whether to go to 12.3 or 13.1.

    SDK v12.3.0 Release notes say that there has been «Fixed a bug in Peer Manager which made it possible for Peer Manager to corrupt the flash memory under certain circumstances». SDK v13.0.0 Release notes say that there has been « Fixed a bug where Peer Manager corrupted FDS data in flash». Is this a different description of the same bug? Or is this bug not relevant when using “fstorage” instead of “FDS”?

    Hmm, I have realized now that there is an other aspect as well: According the release notes of Softdevice S132 v4.0.2, I don’t see a reason for an update. But according nRF52832 Errata Rev 1, SoftDevice S132 v4.0.2 includes workarounds for two anomalies ([102], [106]).

Reply
  • 0 in reply to MartinBL

    Hi Martin,

    Thanks for your answer. I think, there is no reason to go to 14.x unless I need one of the new features. So far, I only have to decide whether to go to 12.3 or 13.1.

    SDK v12.3.0 Release notes say that there has been «Fixed a bug in Peer Manager which made it possible for Peer Manager to corrupt the flash memory under certain circumstances». SDK v13.0.0 Release notes say that there has been « Fixed a bug where Peer Manager corrupted FDS data in flash». Is this a different description of the same bug? Or is this bug not relevant when using “fstorage” instead of “FDS”?

    Hmm, I have realized now that there is an other aspect as well: According the release notes of Softdevice S132 v4.0.2, I don’t see a reason for an update. But according nRF52832 Errata Rev 1, SoftDevice S132 v4.0.2 includes workarounds for two anomalies ([102], [106]).

Children
No Data
Related

core_v2_widget.Hide()