Bluetooth: Direct Test Mode on NFR5340DK

[Rantanplan]

Hello,

after some trial and error, I managed to use the "Bluetooth: Direct Test Mode" example with NCS 2.7.0 (Sysbuild) and USB.

Now I'm questioning myself how to correctly add the source code of the remote_shell (running on the app core) to my project.

I would be very thankful for any hints how this can be done.

And finally, I would like to use MCUboot on a second USB_CDC_ACM to update the network and the app core. But since the Direct Test Mode example uses the net core as main CPU and the app core as child, I don't know if this can work at all.

Many thanks for your answers in advance.

Kind regards,

Christian

[Rantanplan]

Hello again,
I'm sorry for the stupid question above. I found my mistake and now able to use the source code of the remote shell.

Anyway, I still asking myself if there is a simple way to add a boot loader to this project.

7585.direct_test_mode.zip

Many thanks for your answers in advance.

Kind regards,

Christian

[Einar Thorsrud]

Hi Christian,

DTM is not intended to be included in the production firmware. So the solution to the questions should be to keep DTM separate. To use DTM, build and program the DTM example (with minimal changes needed to adapt to your hardware). There is typically no reason to include DTM in the production firmware (and not easily doen as the SoftDevice Controller does not support DTM).

Rantanplan said:

Anyway, I still asking myself if there is a simple way to add a boot loader to this project.

As DTM is used for Bleutooth qualification testing in a lab setting you typically only need SWD for that, and not DFU. (That said, if you for some reason want DFU, serial recovery in MCUboot could be an option, and in that case it would be independet of the application. A colleague of me has made some unofficial samples here that demonstrate serial recovery).

[Rantanplan]

Hi,

true, it will be a separate firmware for lab testing. Since they want to test intermodulation effects with another transmitter, we have to add some functionality to the app core to control this transmit IC via SPI.

And you are right, if the test lab requests some change, it might be easier to tell them how to update via SWD.

Just for my curiosity: Is there a way to use MCUboot in the bootloader (for serial recovery) and a second MCUboot in the application (for OTA updates using Bluetooth)? Just to have a fallback if the MCUboot in the application does not work. How could this be configured?

Many thanks and kind regards,

Christian

[Einar Thorsrud]

Hi Christian,

It is possible to use DFU over BLE in the application and also have serial recovery in MCUboot. There will only be a single MCUBoot instance in this case as well, and the DFU transport is handled by the application when usin gBLE  t(ere is no BLE transport for MCUboot). There is no conflict between these two approches. For DFU over BLE, the main thing is to add an SMP server and SMP bleutooth service. This is for isntance demondrated by the SMP server sample with overlay-bt.conf. If you also add the requiered configs for serial recovery (as shown in the samples in my previous post), you will have support for both. Serial (USB or UART) is a special case, and is the only transport that is supported within MCUboot.

Br,

Einar

[Rantanplan]

Hi, 

sorry, this graphic confused me a bit.

As I understood, there is only 1 MCUBoot instance which can get data via a serial interface (serial recovery). 

But there can additionally be a SMP server in the App can receive data via e.g. Bluetooth and put it somewhere in Flash (secondary slot). At the next boot, MCUboot will recognize the new firmware in this slot, swap it to the primary slot and run it.

Many thanks for the clarification.

Kind regards,

Christian