• State Verified Answer
  • Locked Locked
  • Replies 1 reply
  • Subscribers 89 subscribers
  • Views 2092 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 284117
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

using Softdevice S140 7.3.0 with nRF5 SDK 17.1.0 and nRF52840

Sydney

I have an nRF52840 + nRF5 SDK 17.1.0 project that has been running on S140 7.2.0 and we're getting ready to lock some things in. But we happened to notice that there is a newer S140 - version 7.3.0. While we still can, I wanted to test it out to see if we should update. So I downloaded S140 7.3.0 from nordicsemi.com and noticed the directory structure is a little different from the s140 directory included in the SDK, but it was still pretty straightforward to modify my project file to use the slightly different directory structure. But when I compiled, I got an error because sdk_resources.h references nrf_sd_def.h, which was in the SDK's original s140/headers but is not in the new Softdevice's s140_nrf52_7.3.0_API/include directory.

So a couple of questions:

  • Does the new Softdevice's include directory intentionally not include nrf_sd_def.h?
  • I got it compiling by copying the old nrf_sd_def.h file into the new Softdevice's include directory. Should I have to do this? It seems weird that this was the only file that was missing.
  • Should I be taking a different approach to using the new Softdevice? Maybe I should simply swap out the Softdevice hex files instead of trying to use the headers that came with the new Softdevice?

Thanks.

  • +1

    Hi,

    Does the new Softdevice's include directory intentionally not include nrf_sd_def.h?

    Yes. The file "nrf_sd_def.h" is something that the SDK adds, not part of the "stand-alone" SD download.

    I got it compiling by copying the old nrf_sd_def.h file into the new Softdevice's include directory. Should I have to do this?

    Yes, that's the correct approach.

    Should I be taking a different approach to using the new Softdevice?

    No.

    Maybe I should simply swap out the Softdevice hex files instead of trying to use the headers that came with the new Softdevice?

    No, update the headers and replace the hex file is the correct approach. 

Related
Terms of service