This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Why does softdevice update with DFU not work

I have a working custom DFU bootloader based on the official bootloader from the SDK 8.1.0. Updating the normal application code works without any problem. Now I want to also update the softdevice (currently S120). Therefor I generated the update .zip file with the tool included in the MasterControlPanel version 3.9.0.6. I used the following command on the CMD:

nrf.exe dfu genpkg --softdevice s120_softdevice.hex --dev-type 0xffff --dev-revision 0xffff --sd-req 0xffff SD_DFU.zip

But when uploading this .zip file to the bootloader with the nRF Connect Android App, I can see that the bootloader breaks the communication after prevalidating the init package.

I can see that dfu_init_pkt_complete(); in dfu_transport_ble.c returns NRF_ERROR_INVALID_LENGTH. This comes from the dfu_init_prevalidate(...)function in dfu_init_template.c. The check:

if (((uint32_t)p_init_data + init_data_len) < 
        (uint32_t)&p_init_packet->softdevice[p_init_packet->softdevice_len])

goes wrong, and NRF_ERROR_INVALID_LENGTH is returned. Is it a problem on the bootloader side, or is it a problem with generating/transmitting the .zip file? Any help appreciated.

BR, BTprogrammer

  • One thing I noticed is that you have set the --sd-req to 0xffff and not 0xfffe (0xfffe = bootloader accepts any SD). So could you try to create an image with the following command?

    nrf.exe dfu genpkg --softdevice s120_softdevice.hex --dev-type 0xffff --dev-revision 0xffff --sd-req 0xfffe SD_DFU.zip
    

    But I dont think this should lead to the NRF_ERROR_INVALID_LENGTH, but its worth a try.

  • Hello Bjørn, thanks for your advice. Unfortunately this does not solve the problem. The expected legth seems not to match with the transmitted length...!? I tried it also with the official bootloader from SDK11. There is doesn`t work, also. So at the moment I think there is something wrong with generating the .zip file. Another assumption is that there is not enough flash space to store the new SD. But I am using the 256k nRF51 version. Does the bootloader automatically overwrite the aplication stored in flash? I expect that the new sofdevice is automatically stored above the already existing sofdevice. And if the transmission was successful, the old softdevice will be overwritten by the new one. Right?

  • I assume that you have modified the S110 bootloader as described in this post. Could you try to update MCP to the latest version 3.10.0 and see if that solves the issue?

  • Good morning Bjørn, thanks for that advice with the new version. When generating the package with the new nrfutil - tool, and using the standard bootloader from the SDK 11 it works and the new softdevice is uploaded. Unfortunately my custom bootloader (based on SDK8.1.0 bootloader) now breaks on a later point. I get an error NRF_ERROR_NO_MEM from hci_mem_pool_rx_produce(...) called from app_data_process(...) (dfu_transport_ble.c). Maybe you have also any idea about that?

  • Could you verify that the defines in hci_mem_pool_internal.h is set to the following

    #define TX_BUF_SIZE       4u    /**< TX buffer size in bytes. */
    #define RX_BUF_SIZE       32u   /**< RX buffer size in bytes. */
    
    #define RX_BUF_QUEUE_SIZE 8u    /**< RX buffer element size. */
    

    If then are, then you can try to increase the RX_BUF_QUEUE_SIZE from 8u to 16u, i.e.

    #define RX_BUF_QUEUE_SIZE 16u    /**< RX buffer element size. */
    
Related