Why is a baremetal bootloader using Zephyr code?

[Randy Lee]

I'm attempting to put together an application using the baremetal version of NCS just released... I need these to run DFU over BLE so we can update in the field.

I created the project using the sample from that release of a bootloader itself and was surprised to see it referencing Zephyr code which is going to make this harder to do.

So why is this using this code base when it would be much simpler to used the SDK code base of bootloaders (this NCS version is running a softdevice so it shouldn't be a trick to use it)?

Is this implementation of DFU different than the SDK implementation of it?

A related question: I need the advertising name to be dynamic based on the MAC address..  How do I do that in this or the regular NCS implementation?

TIA

[Edvin]

Hello,

there are traces of zephyr in both the bootloader and the application, but the difference is that it is not using the full Zephyr RTOS. 

So the idea is not that it should be 100% Zephyr free, but it should be a simpler SDK for simple applications. 

You shouldn't need to do much changes to the bootloader, other than changing from the default keys, so I don't really see how the amount of zephyr in the bootloader really is an issue.

You can read about the similarities and differences between the nRF5 SDK bootloader and the NCS BM bootloader here:

https://docs.nordicsemi.com/bundle/nrf-bm-latest/page/migration/nrf5_bm_migration_5.html#dfu

Also, the Application DFU section and the SoftDevice and Firmware Loader update section are explaining in a bit more detail how the new bootloader works. That said, when you are running a DFU, you don't need to know all the details on what's going on. The files are automatically generated when you build for a board with the bootloader included, and the process from a phone app standpoint is no different than it is for an NCS application, which uses mcumgr to transfer the image.

I have not tested, but it looks like by default, the advertising name is set to the CONFIG_BLE_ADV_NAME in ble_adv_init() from ble_adv.c. CONFIG_BLE_ADV_NAME is defined in prj.conf.

I believe the easiest way to update the advertising data (including the advertising name), is to use ble_adv_data_update() directly. This does require you to build up your ble_adv_data *adv_data and ble_adv_data *sr_data manually. For this, you can use ble_adv_data_encode(), or you can read up on how an advertising packet is built up. It is described briefly here:
https://academy.nordicsemi.com/courses/bluetooth-low-energy-fundamentals/lessons/lesson-2-bluetooth-le-advertising/topic/advertisement-packet/

Basically, each advertising packet has one or more data structures that consists of 1 byte of structure length, one byte of AD type, and then length-1 bytes of payload.

Best regards,

Edvin

[Randy Lee]

Thank you for the pointers here.. much appreciated.

Uffda...

I have code in my existing projects that modifies what Nordic does and catches particular traps coming from the application.  Basically the application is the thing that tells the bootloader to boot and go into DFU mode for updates after being commanded to through BLE commands.  Most of my apps assume DFU coming in from BLE although I have one that assumes it is in the attached QSPI in a partition set aside for that purpose. So I need to modify you boilerplate code to add these hooks.  In SES, I have a directory in me project that is Nordic code but modified and then tell the IDE to ignore the one in the Nordic directory structure.  Should be able to do something like that with VS Code I should think.

To quote from one of the pointers you shared:

The protocol used to upload new images to the device has also changed. The previous nRF5 SDK solution utilized a Nordic proprietary DFU protocol, while Bare Metal adopts the MCUmgr SMP protocol, which is also used in the nRF Connect SDK.

Now here's the interesting bit: This MCUboot thing uses a completely different protocol than Nordic SDK DFU.  Our apps connecting to this hardware have DFU baked into them so the user can do firmware updates within our apps, which means that these firmware code bases are completely non-interchangeable in the field and a) we'll have to ADD this SMP to all our apps that allow this and b) we'll have to figure out how to make it clear to the app which protocol to use. This is bad.

So here's an interesting question: Is it probable (anything is possible) that I can take and make this "bare metal" approach a lot more bare metal than it is by merging the conceptual systems here?  That is to say that if Nordic is fully going to support this version of "bare metal" going forward then that implies 2 things: 1) that the softdevice is going to be an equal partner to the Zephyr version (I'd like to have that confirmed or denied), i.e. that it will support BT6.0 itself and 2) that it will support future chipsets.

Now if both of those are true, what's the probability of using the basic framework of SDK with a new Softdevice (and associated .h files) along with the startup code for the new parts?  

-OR-

would it be easier to replace MCUboot with the SDK bookloader?

[Edvin]

The NCS Bare Metal SDK will not be an equal partner to the Zephyr version. The Bare metal is for simple BLE applications that does not require any of the OS features that comes with Zephyr, and it will not have new features such as Channel Sounding, LE Audio etc. It is more or less a snapshot of the latest nRF5 SDK. 

Right now, it also only supports being a BLE peripheral. Whether or not that will change I don't know. You would need to reach out to our sales department for roadmap details. Send me a direct message her on DevZone if you want the contact info for your area.

Randy Lee said:

would it be easier to replace MCUboot with the SDK bookloader?

I am not sure about this. The SoftDevice is at the top of the flash in the bare metal SDK, so it is not trivial to do this. Probably not impossible, but not something that we are planning to do.

But I do want to underline this. The Bare Metal SDK is not intended to be "as good" as the nRF Connect SDK (full fledged version), packed with all the same features. It is intended for those who wants to reduce the time for development, because it doesn't have as many details you need to familiarize yourself with. But if you need more features than what the softdevice can offer, we recommend that you move on to the full NCS.

Best regards,

Edvin

[Randy Lee]

Got it... Thanx...