This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF91 firmware upgrade over BLE

Hi,

I am trying to do firmware upgrade of nRF91 over BLE using nRF52 on the nRF91-DK or Thingy91 board. They both have nRF91 and nRF52840 chips on them which are connected. 

As I understand from the documentation, at the moment, on Thingy91 board I can connect to the USB (which is connected to the nRF52) and upgrade the firmware on nRF91. This is also providing two UART ports, and the BLE UART service can be additionally enabled. Like in example: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/applications/connectivity_bridge/README.html

On the nRF91 side, nRF91 application would have to implement the UART management transport so it can be upgraded over UART and the nRF5x act as a bridge from BLE to UART
https://docs.zephyrproject.org/1.13.0/subsystems/mgmt.html

Is this a good way to go and do you have some experience doing this?

At the moment I have a bit different approach. I started with nRF52 app_ble_uart example and created the "UART bridge" between BLE device and nRF91. Next is to have nRF91 able to receive upgrade and probably write some application for PC/mobile deice to push the upgrade over UART. 

Let me know your thoughts and if you already have done something like this. 

Best regards,
Vojislav.

Parents
  • If I understand you correctly, you want to transfer a firmware image in the following manner: [ BLE Device ] →BLE→ [ Thingy/91 DK (nRF52→UART→nRF91) ].

    Regarding the transfer from the nRF52840 to the nRF9160, it can be achieved by following the steps in my last comment (at the moment) in this thread. In that thread, the roles are switched (Serial DFU from nRF9160 to nRF52), but the process should be the same.

    I need some more time to answer your question fully but I will try to get back to you within this week.

    Best regards,

    Simon

  • Hi Simon,

    You understood well what I want to do. 
    In the meantime, I will investigate more what you wrote in the thread you mentioned. 

    Ad this moment do you think it is better to go with nRF5 SDK or NCS/Zephyr on the nRF52 chip?
    An additional request from my side is if you are trying something on hardware please do it on nRF91-DK as I only have that board with me at the moment due to current the situation in the world.

    Thank you and looking forward to your response.  

    Best regards,
    Vojislav

  • I suppose that this tread needs to be changed:

    void ble_write_thread(void)
    {
    	/* Don't go any further until BLE is initailized */
    	k_sem_take(&ble_init_ok, K_FOREVER);
    
    	for (;;) {
    		/* Wait indefinitely for data to be sent over bluetooth */
    		struct uart_data_t *buf = k_fifo_get(&fifo_uart_rx_data,
    						     K_FOREVER);
    
    		if (bt_gatt_nus_send(NULL, buf->data, buf->len)) {
    			printk("Failed to send data over BLE connection\n");
    		}
    
    		k_free(buf);
    
    		if (rx_disabled) {
    			rx_disabled = false;
    			uart_irq_rx_enable(uart);
    		}
    	}
    }

  • What I have tested is that if I remove waiting for '\r' or '\n' or full buffer and send character but character, the mcumgr tool cannot process that (this is not in the code above, but it is in the main.c of peripheral_uart). From what I see in the connectivity_bridge project they are using hardware flow control for understanding when UART write from nrf91 is done, and then send that data over BLE NUS or to the USB. 
    So my question is do you think we can do this in software or is it necessary to do in with CTS and DTS pins like on Thingy91?

    Best regards,
    Vojislav.

  • I am sorry for the delay. I will look into your issue on the next working day (which is Tuesday due to Norwegian holiday on Monday).

    Best regards,

    Simon

  • Hi Simon,

    I wish you a happy holiday! 

    This is the current situation regarding this issue:

    • I have three boards connected: nrf91-DK (mcuboot with hello_world app) connected with jumper wires (UART RX, TX, and GND) to the nrf52-DK (nrf52832, this runs peripheral_uart app) and nrf52840-DK (nrf52840, this runs central_uart app).
    •  So now I have bidirectional communication in this path: myPC <-USB-> nrf52840-DK <-BLE-> nrf52-DK <-UART-> nrf91-DK. 
    • I do not anymore have a problem with the termination of UART messages because I used logic analyzer and sniffed the messaged going back and forth on the UART and saw that responses that nrf91 is sending to mcumgr CLI also have a termination, and this was not written in the mcumgr serial documentation
    • with all this, I am able to send the mcumgr CLI command for reset over my "BLE UART" while the device is in the serial recovery mode and the device will reset and go to the application. This command has rather small send and receives the command, and that is ok for current application
    • now at the last step problem is because firmware upgrade sends much bigger data packets and because BLE is sending it in chunks od 20 bytes a timeout happens at mcumgr CLI application.

    So I was looking to extend buffer size on both ends (peripherial_uart and central_uart) but just setting the buffer to some bigger value is not enough, do you have some tips on this and what else is necessary to achieve bigger buffer size on both ends?

    Best regards,
    Vojislav.

  • So what I see now, from investigating this further is that I have a problem in one direction:

    • peripheral to central BLE device is working OK, and sending a lot of data at once
    • central to peripheral is outputting 20 but 20 bytes on the UART.

    Do you think this has to do with BLE central buffer or BLE peripheral buffer?

    Best regards,
    Vojislav

Reply Children
Related