Choice of SDK for nrf52805 beacon

RE: Choice of SDK for nrf52805 beacon

AHaug — Thu, 19 Oct 2023 08:54:20 GMT

Hi Oliver,

Thank you for your patience and apologies for the long wait. It's been a busy week

[quote user="opasutto"]So, I think that this product should have the role of an BLE central device (connecting to a BLE peripheral to gather data and controlling it), do you agree? There is maybe a possibility to have a communication between 2 BLE peripherals but I don't know it...[/quote]

Yes, that design works as long as you have enough ROM to fit everything

Communication between two peripherals will in practice result in that one of the devices needs to have a central role

Another option could be to implement the remote controller as a peripheral device that starts advertising when the button sequence is pushed and having the larger device you mention as the central which scans for the advertisement and connects to the remote controller. This could allow you to use SD112/113 instead of SD132. Do note that if your remote controller is supposed to be a central device that bonds (not pairs/connects) you will need an additional ~8kB for the bonding feature.

I'm not stating that this is the best solution, simply throwing this out as an alternative

[quote user="opasutto"]Now, when I check the 52805 compatible softdevice, it seems that only peripheral role SD are available (S112/S113). I think this makes the nrf52805 incompatible for our product?[/quote]

I agree with your findings. SD112/113 does only support peripheral roles. So another option is to use NCS if you wish to use the 52805. I will expand about this in the reply to your question regarding memory capacity

[quote user="opasutto"]What about the nrf52810? It seems that it is compatible with the S132 allowing central role. Any reason why the S132 is compatible with 52810 and not 52805 although they have the same memory capacity (too bad, the 52805 is a bit less pricey)?.[/quote]

Based on some discussion with a colleague of mine it is due to testing and qualification of the softdevices on the devices.

[quote user="opasutto"]From the compatibility matrix of the 52810 it seems that I will have to use however the SDK 14.2 along the SD132 v5.1 as the SDK 17.1 doesn't seems compatible with SD132?[/quote]

I am still waiting for a verification from the creator of the matrixes regarding this

[quote user="opasutto"]Now regarding memory capacity, I'm conscious that it will be a challenge to have both a central device and DFU in a 52805/810? Even if our application will be very simple and we don't need secure bootloader or double bank. You have maybe an advice about this...[/quote]

Now this is most likely the question that narrows down the choice for you.

The first thing you will need to decide is the type of DFU you wish to have. Is it Serial Recovery, you might be able to get away with a small device as you don't need two application slots, and simply let the Bootloader overwrite the application instead. There should be samples for how to do this in nRF5 SDK and you can see https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/serial_recovery for serial recovery (and some theory behind it) in NCS in the github repository. With a footnote that serial recovery in nRF5 will add some extra ROM load due to having to create a bootloader that supports both serial recovery and BLE transport.

If you end up with nRF5 SDK and the 192kB devices you will be limited with what you can update if you don't use the equivalent to Serial recovery. In the case of "regular" DFU, you can most likely never update the Softdevice i.e have full DFU support since you won't have enough room. Your application will also have to be relatively small, and there needs to be room on the device to perform the update so it might not differ too much from NCS w.r.t ROM if you wish to have full DFU support.

Regarding NCS I don't have any numbers for how large an optimized Bluetooth Central + DFU is in NCS. When compiling the Central_uart sample without optimizing anything and before adding DFU the sample uses ~240kB, meaning you will have to have the nRF52832 (512kB) or an external flash if you wish to add DFU support. When building the zephyr smp_sample with the BLE overlay, the application uses ~234kB before optimizing anything, also meaning that you will need a total of 512kB for DFU support on the internal flash.

This will unfortunately require some more testing from your end w.r.t what you wish to fit. A third option which fits for both nRF5 SDK and NCS is to add an external flash you can use to store the update image on for DFU and use SPI/QSPI between the nRF and the flash device. This alternative might be cheaper than having a 512kB device.

[quote user="opasutto"]We could maybe switch to an nrf52832, but the price difference will probably push us to drop out the DFU functionality and stay on the nrf52810.[/quote]

It is very understandable that the jump to nrf52832 is too large w.r.t price and also w.r.t what your device is intended to do based on your description. Adding full DFU support does unfortunately add a doubling of ROM requirements since

To summarize what I believe might be the best choice for a small device that is most robust for the future

NCS with serial recovery DFU
Optimize the bootloader and application w.r.t ROM as much as possible
Alternatively add an external flash if you have an available SPI if you wish to use anything other than serial recovery, i.e two application slots for "proper, safe" DFU where you don't overwrite your application before verifying that your new image runs.

Kind regards,
Andreas

RE: Choice of SDK for nrf52805 beacon

opasutto — Fri, 13 Oct 2023 12:36:48 GMT

[quote userid="107683" url="~/f/nordic-q-a/104633/choice-of-sdk-for-nrf52805-beacon/450298"]

I will however need some time to answer some of them, so I won't be able to return with an answer to you before middle of next week (tues/wed, but hopefully Monday).

I hope that is acceptable for you

[/quote]

No problem, I will continue experimenting with the nrd52DK eval board during this time.

Best regards,

Olivier

RE: Choice of SDK for nrf52805 beacon

AHaug — Fri, 13 Oct 2023 12:27:09 GMT

The questions looks to be within the same topic so lets keep them here!

I will however need some time to answer some of them, so I won't be able to return with an answer to you before middle of next week (tues/wed, but hopefully Monday).

I hope that is acceptable for you

Kind regards,
Andreas

RE: Choice of SDK for nrf52805 beacon

opasutto — Fri, 13 Oct 2023 12:17:35 GMT

Hi,

I already have other questions ( I don't know if I have to post to post this question on another thread, I will if needed)!

After some reflexions and investigation, I have now some doubt about the choice of the nrf52805.

First let me describe a bit more our needs for this product:

We are designing a small remote control with one button and 2 leds that will be powered by a 3V coin cell battery. When not used the product will be put to deep sleep, and after a specific sequence with the button, the remote control will connect to a paired BLE peripheral (based on an nrf52832/810) to control it and retrieve its state that will be indicated on the LEDs, and then going back to sleep. The product will have to be small and at a relatively low cost.

So, I think that this product should have the role of an BLE central device (connecting to a BLE peripheral to gather data and controlling it), do you agree? There is maybe a possibility to have a communication between 2 BLE peripherals but I don't know it...

Now, when I check the 52805 compatible softdevice, it seems that only peripheral role SD are available (S112/S113). I think this makes the nrf52805 incompatible for our product?

What about the nrf52810? It seems that it is compatible with the S132 allowing central role. Any reason why the S132 is compatible with 52810 and not 52805 although they have the same memory capacity (too bad, the 52805 is a bit less pricey)?.

From the compatibility matrix of the 52810 it seems that I will have to use however the SDK 14.2 along the SD132 v5.1 as the SDK 17.1 doesn't seems compatible with SD132?

Now regarding memory capacity, I'm conscious that it will be a challenge to have both a central device and DFU in a 52805/810? Even if our application will be very simple and we don't need secure bootloader or double bank. You have maybe an advice about this...

We could maybe switch to an nrf52832, but the price difference will probably push us to drop out the DFU functionality and stay on the nrf52810.

Thank you again for your advices.

Olivier

RE: Choice of SDK for nrf52805 beacon

AHaug — Fri, 13 Oct 2023 07:50:03 GMT

Happy to hear that!

[quote user="opasutto"]I will come back to you if I have other questions![/quote]

Please do :)

Kind regards,
andreas

RE: Choice of SDK for nrf52805 beacon

opasutto — Thu, 12 Oct 2023 16:16:45 GMT

Hi Andreas,

Thank you for your response it was very clear!

I'm gonna try the BLE Secure DFU Bootloader example on the 52805 to check the remaining memory for the application.

I will come back to you if I have other questions!

RE: Choice of SDK for nrf52805 beacon

AHaug — Thu, 12 Oct 2023 12:12:38 GMT

Hi,

[quote user=""]First do you think the choice of the nrf52805 is appropriate for our product.[/quote]

Yes, but there will be severe limitations to the size of your applications w.r.t. ROM if you at a later point realize you need to add more features and or if you need more peripherals than you originally had planned for.

Personally I would recommend to develop the application and all you need on a larger device (if you have a 52840DK, 52DK or 52833DK available) with all the features you need to have and then see if you can fit that within the limitations of the 52805 before ordering in bulk unless you are very certain that you can fit it within the device

[quote user=""]Next we have to choose which type of SDK to use, we have some experience with the traditional nordic SDK, but never have used the new Connect SDK (not available during the conception of our peripheral). Do you recommend starting the development of our new product with the connect SDK? The limited amount of memory is maybe not compatible with the integration of an RTOS?[/quote]

Due to the small amount of flash on the nRF52805 we typically recommend to use nRF5 SDK for that device, specially if you wish to have DFU support. When using the nRF52805 with nRF5 you can pick the Softdevice that suits the device as well as your application based on the features you need giving you some more leeway when it comes to fitting your application with DFU support.

If you end up with a device that's larger than the 52805 (for instance the 256kB 52832 or the 512kB 52833), I would recommend you to use NCS due the continual support NCS will have in the years coming, and since nRF5 SDK is in maintenance mode so no new fixes and features will be added to that SDK. See this statement for more information nRF Connect SDK and nRF5 SDK statement

Do note that this is not a statement that says that you can't use NCS for the nRF52805, but if you wish to add DFU support you will in practice reduce the available flash space to less than half since you will be adding MCUboot and a secondary application slot for the update image.

This blog also highlights some of the differences in ROM and RAM usage in between NCS and nRF5 SDK Debunking misconceptions: A technical analysis of nRF5 SDK and nRF Connect SDK

[quote user=""]If we start with the traditional SDK, which version of SDK and softdevice is advised? fI have read these links: SDKs and SoftDevices and Developing for the nRF52805 with nRF5 SDK. If I understand correctly, I can use the latest SDK (17.1.0) with S112 but I will have to patch the SDK? Correct?[/quote]

If you're going with nRF5 SDK we recommend the newest, i.e 17.1.0. The SoftDevices compatible with the nRF52805 are the ones listed on the first link you refer to. The blog you mention refers to how you can emulate the 52805 on a nRF52DK or nRF52832, but to my understanding it is not required to follow that patch for simply developing for the nRF52805 unless you're testing your firmware on the two devices the blog mention

Let me know if this clarifies things for you and if you have any additional questions!

Kind regards,
Andreas