Dear Community;
Is it possible to flash a .hex file to an nRF 9160 DK using Bluetooth? Something similar to nRF programmer but using Bluetooth instead of USB OTG cable.
Thanks.
Dear Community;
Is it possible to flash a .hex file to an nRF 9160 DK using Bluetooth? Something similar to nRF programmer but using Bluetooth instead of USB OTG cable.
Thanks.
Hi.
It is not something that we have at the moment, but all the building blocks should be there.
The solution would look something like this:
You need an application on the nRF52840 that can receive the new image. Then, when the image is received it must transfer it to the nRF9160 over UART (or other serial protocol). The new image can also be streamed over the UART as it comes in without waiting to receive it all first.
On the nRF9160, you have two options for how to receive the image.
1. MCUBoot with "serial recovery". This requires the nRF52840 to be able to reset the nRF9160 while holding a pin high (or low, depending on the configuration of MCUBoot). Then after the reset, MCUBoot will run, which will check the pin value. If the pin is asserted, MCUBoot will enter serial recovery mode, meaning that it will be able to receive a new image over UART. When the image is received, the nRF9160 must be reset before it will start to use the new image.
2. The application on the nRF9160 will receive the new image and write it to the secondary image slot in flash. Then, the application will trigger a reset. After the reset, MCUBoot will detect the new image, and boot that.
A third option is to run the Bluetooth host layer on the nRF9160 and run the hci_uart sample on the nRF52840. That way, you can program the nRF9160 as if it has Bluetooth.
In both cases 1 and 3 (and optionally in 2), you must use the SMP protocol.
You can find more information here:
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.3.0/mcuboot/wrapper.html
Best regards,
Didrik
Hi.
Sorry for the late reply. I am considering the third option. I am able to run hci_uart sample on the nRF52840. What do you mean with "run the Bluetooth host layer on the nRF9160"? Could you provide more information about that?
Thanks!
The Bluetooth stack can be split into two layers: The controller and the host.
The BLE controller is responsible for the actual link and is controlling the radio.
The host layer handles the non-real-time parts of the BLE stack and is what the application is interfacing with.
As the host layer is separated from the radio and does not have any real-time demands, it can be run on a separate processor from the radio/BLE controller.
You can see this in action in the lte_ble_gateway sample, which sends sensor data from a Thingy:52 to nRF Cloud.
Some more information:
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/guides/bluetooth/index.html
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_ble_controller.html
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrfxlib/ble_controller/README.html
The Bluetooth stack can be split into two layers: The controller and the host.
The BLE controller is responsible for the actual link and is controlling the radio.
The host layer handles the non-real-time parts of the BLE stack and is what the application is interfacing with.
As the host layer is separated from the radio and does not have any real-time demands, it can be run on a separate processor from the radio/BLE controller.
You can see this in action in the lte_ble_gateway sample, which sends sensor data from a Thingy:52 to nRF Cloud.
Some more information:
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/guides/bluetooth/index.html
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_ble_controller.html
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrfxlib/ble_controller/README.html
Hi,
Thank you for the more detailed explanation.
Best regards.