BL653 crashes when working with CONFIG_MCUMGR_SMP_BT & CONFIG_ESB

[Vagner Landskron]

Hello everyone,

We're trying to create an application that has 2 modes, one is running our regular application and upon a special command, it switches to a "DFU" (via device manager) mode.

In the DFU mode I've adapted the example here:
https://github.com/nrfconnect/sdk-nrf/blob/main/samples/bluetooth/peripheral_lbs/src/main.c

It happens that this application requires the prj.conf directives: CONFIG_ESB & CONFIG_MCUMGR_SMP_BT.

I've compiled and flashed the application to the device. Application starts and automatically starts to listen for ESB packets(PRX).

As soon as it gets a packet, the application crashes without any information - even though I'm not advertising or working with regular BT (only ESB for BLE).

Disabling the directive CONFIG_MCUMGR_SMP_BT leads to a working version (but without DFU support).

Is there a way to overcome this issue?

Alternative, is there an example of how to access the mcuboot and switch image slots during runtime?

[Sigurd Hellesvik]

Vagner Landskron said:

To be honest, I feel like I'm over-complicating this. 
What I really need is a way to upload my application, over-the-air.

Hi,

Good job on realizing what you really need! (See XY problem)-
I agree that adding multi-protocol to your project might be too complicated, and probably should realized this in my last answer.

Now to what you are asking: How to do over the air on an ESB application?

MCUboot does not really care how the new firmware image is written to flash, as long as it is formatted correctly.
Unfortunately we do not have any functionality for SMP over ESB. So you will have to add it yourself.

We have some start points for this, which I will show you shortly.
But first a downside with ESB Over-the-air DFU:
Since mobile phones does not support ESB, you need a "DFU sender" to send the update as well.
For example 2x nRF52833DK, one to send the update and one to receive it.

So how would I suggest to solve this?
MCUboot use the SMP protocol to do DFU.
A SMP Client sends a firmware image to a SMP Server. Then the device with the SMP Server is updated.
If you want to know more about how this works, see some unofficial bootloader theory by me.

We have an SMP Server example for BLE as you know.
This use the zephyr mcumgr subsys to handle communication.
As you see in this folder, there is "transport" folder.
In theory, you should be able to add a new trasport here for ESB.

We do not have an official SMP Client sample, and from when I said previously, you know that you need to have something to send as well.
However, you can use this unofficial Bluetooth: Central SMP Client DFU sample, and change it to use ESB as well.

So in the end, you see that doing it this way requires you do add an ESB driver to the zephyr mcumgr subsys.
I do not know if this will be more or less work than using MPSL.
But it will be the "cleaner" solution, as your application do not need to switch between BLE and ESB.

This was a long answer. Did it all make sense to you?

Regards,
Sigurd Hellesvik

[Vagner Landskron]

Thanks Sigurd!
Your links leaded me to the answer.

The smp_svr is "erasing" (or marking it as not valid, magic number becomes invalid) the slot once I upload a new image and switch it permanently.

Solution for my problem is to not use this "smp_svr", but something that doesn't invalidate the slot of the application that implements the DFU (i.e, the piece of code in my question).

Sounds like a silly issue, but I had a misunderstanding of the mechanism of "what happens behind the curtains".

Now I'm able to upload my application and from my application to rollback to the DFU mode.