Secure DFU with both BLE + USB transport

RE: Secure DFU with both BLE + USB transport

Hieu — Thu, 10 Aug 2023 13:43:53 GMT

Hi D,

It is great to know that things are working for you now. Thanks a lot for letting us know.

It really is quite mysterious why editing the file with CMSIS could cause an issue. I think an extensive file compare might point out some mismatches. Please let us know if you eventually figure it out someday.

Hieu

RE: Secure DFU with both BLE + USB transport

Dano — Thu, 10 Aug 2023 06:16:22 GMT

Hi Hieu

Well I tried another fresh SDK and SES 5.42a and got the same result 4X8X. I decided to start again from the supplied example which I knew worked (in place in the SDK examples/dfu folder). I changed the BLE and USB bootloader names and the same thing happened - however, when I directly altered the sdk.config,h manually, not via CMSIS, it worked!

Interestingly in the sdk_config.h file, just before the define of "APP_USBD_STRINGS_PRODUCT" it says the following:

// <s> APP_USBD_STRINGS_PRODUCT - String descriptor for the product name.

// <i> Note: This value is not editable in Configuration Wizard.

Lets just say it's all working now! I looked at my previous sdk_config.h and they looked the same, but the direct editing approach worked. I will try some other combinations when I have a chance to see what specific combination created the 4X8X error. If I identify a pattern I will add to this post.

I very much appreciate the help.

RE: Secure DFU with both BLE + USB transport

Hieu — Thu, 03 Aug 2023 22:24:30 GMT

Hi D,

I too apologize for delay on my end, I have been out of office and there seem to be some accidents in reassigning your question; but that is resolved now.

Also, thank you very much for the kind words. I will make sure to relay it to my colleague. But that would have to be in a few weeks, because he is unfortunately out of office.

In his absence, I tried to look into it and just like you don't see any difference in sdk_config.h or the project setup.

However, when I proceed to test the bootloader, I see that the serial number appears just fine for me:

This is quite odd. Especially when you don't see the same problem with the USB-only projects.

How are you building this project? If you are using SEGGER Embedded Studio (SES), what version are you using? I recommend using the v5.42a while working with the nRF5 SDK v17.1.0, because that SDK version was tested with that SES version.

Since it is so strange, it might be worth it to try again with a fresh copy of the SDK. Please remember to keep the old copy around in case that it is the problem.

Regards,

Hieu

RE: Secure DFU with both BLE + USB transport

Dano — Sat, 29 Jul 2023 05:22:51 GMT

Hi Hieu

Sorry for the delay in my reply, but many thanks to you and your colleague (please pass on my thanks) - in one word - EXCELLENT!!.

The bootloader compiled easily and I have since added DFU support to my applications. I found writing to the gpregret register to be the simplest. I only had to add #include "nrf_bootloader_info.h" to the applications. The APP command that activated the DFU only required the two lines below and that was it.

sd_power_gpregret_set(0, BOOTLOADER_DFU_START);
NVIC_SystemReset();

Since then I have been creating private keys and batch files to build the final hex and zip files and its all working well.

I do have one query. The usb serial number is not displaying correctly on the combined transport DFU. I assume the usb_dfu_transport_init function is called that includes the function app_usbd_serial_num_generate(), but I am getting 4X8X as the serial number. I have tried several nRF52840 dongles and the DK and all report the same 4X8X.

If I use the usb only DFU it shows correctly on all devices. I have been through the sdk_config.h on both DFU versions and I cannot identify any usb config variations that would cause this. Perhaps this is a consequence of using both usb and ble transports? This leads me to think it is deeper in the SDK and there is something else I need to configure. Could you reach out to your colleague to see if he can resolve this please.

Thanks again

RE: Secure DFU with both BLE + USB transport

Hieu — Fri, 07 Jul 2023 14:52:07 GMT

Hi Dano,

[quote user=""]Surely someone at Nordic has created a DFU with multiple transports - can that code be shared please? [/quote]

Actually yes. A colleague shared this with me when they see your question:

devzone.nordicsemi.com/.../secure_5F00_bootloader_5F00_usb_5F00_and_5F00_ble.zip

Please note that the code is provided as is and without warranty; and we have not performed all the strict test that a normal SDK example went through.

On other note, I think a common challenge is something that mrono brought up. NVIC and SOC APIs are different between when a SoftDevice is used, versus when it is not. This is likely what causes conflict when you are trying to merge the BLE Secure Bootloader with the SoftDevice, and the USB Secure Bootloader that is using NVIC API for no SoftDevice case.

Such APIs for when the SoftDevice is presented are defined in SDK\components\softdevice\s***\headers, where the one for when the SoftDevice is not presented are defined in SDK\components\drivers_nrf\nrf_soc_nosd

In your attempts, please remain aware of those files, and make sure only the correct files are included in your project.

Beyond this tip, if you have any specific error that you would like to resolve, please give me the details and I will try to support you.

By the way, please be informed that it is the summer vacation period here, and we are understaffed. Please excuse delays in responses in the upcoming week. My apology for the inconvenience.

Hieu

RE: Secure DFU with both BLE + USB transport

mrono — Fri, 07 Jul 2023 12:01:44 GMT

I'm sorry that I can't really help, but something fundamental is wrong with your project. Take the first error:

7> E:\OneDrive\Code\nRF\_DDO\SDK\components\libraries\util\app_util_platform.c:44:1: error: unknown type name 'nrf_nvic_state_t'

app_util_platform.c includes app_util_platform.h which in turn includes nrf_nvic.h, which defines nrf_nvic_state_t. The only macro involved here is SOFTDEVICE_PRESENT. Yet there are no errors about missing include files. I don't understand how that type is not found.