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

DFU SDK13. Problems with update. Starnge behavior.

I implemented DFU secure ble. And implemented encryption. But now I remarked strange behavior. If make same DFU packet (.zip) and flah nRF52 than update firmware for same packet DFU- all OK. If flash nrf52 one firmware and than make small changes in the project and make DFU and update it- all OK. But if I make in project to many changes (compile same project from one optimization (-0) to 3nd optimization, for example) and than flash via DFU- project doesn't works. Project starts with new firmware and always has reboot.

As recommended I made next changes:

in a file dfu_req_handles.c

insert to line 589

case DFU_FW_TYPE_APPLICATION:
                p_bank->image_crc = crc32_compute((uint8_t *)MAIN_APPLICATION_START_ADDR, m_firmware_size_req, NULL);

line 637 just comment:

#endif
        // Calculate CRC32 for image
//        p_bank->image_crc = s_dfu_settings.progress.firmware_image_crc; // az comment
        p_bank->image_size = m_firmware_size_req;

and between 1004 -1005 and 1044-1045 I insert block for decrypt image:

for (int i = 0; i < m_data_buf_pos; i+=16)
                {
                    AES128_ECB_decrypt (&m_data_buf[m_current_data_buffer][i], key, &m_data_buf[m_current_data_buffer][i]);
                }
 

at this changes I received wrong CRC in a file components/libraries/bootloader/dfu/nrf_dfu_utils.c

I just made changes in line 165;

s_dfu_settings.bank_1.image_crc = crc;

therefore I just ignore if CRC was wrong, but didn't decide real problem.

How to correct make changes for normal work DFU with encryped image?

  • Hi,

    line 589 seems to calculate the checksum of the application image in bank 0, so will not be valid if you do a dual-bank update as the new image will be stored in bank 1. Maybe that's what you are seeing; bootloader performs single bank update when you compile the app without compiler optimization due to limited flash space, and dual bank when you compile with optimization? In any case, I think you need to calculate the checksum of the image in bank 1 when s_dfu_settings.bank_current == NRF_DFU_CURRENT_BANK_1.

     

  • Thanks. Possible You right. But I just check pure dfu_bootloader with no changes and works fine. 

    But I need to encrypt my firmware. 

    Can You advise me in which places should change code for correct unpuck encrypted firmware. And correct I call 2 times AES128_ECB_decrypt ()?

  • Yes the standard bootloader works, but when and where to calculate the CRC changes when you introduce encryption. As I said in my previous reply, it looks like you are calculating the checksum of the old FW image. 

  • Hi! Can You advise me in wich plase should insert CRC check? 

    decrypt in 2 plases did I correct?

    Or if CRC not correct when check it, but in file nrf_dfu_utils.c in the DFU project, I after line 164 add

    s_dfu_settings.bank_1.image_crc = crc;

    Therefore I cheating CRC check and DFU on smartfone write that firmware updated sucessfull.   

  • So. No problems with encreption like I discribe before. All works correct. And AES encription to.

    But my problem has another reason.

    I use block code for non updatable data. I located it 

    volatile type_struct my_struct1 __attribute__((section(".ARM.__at_0x72400"))) = 
    {
      ...
    }
    volatile type_struct my_struct2 __attribute__((section(".ARM.__at_0x72500"))) = 
    {
      ...
    }

    At this case this struct not updated from bootloader. But in the .hex after compile I have some code after 0x72500. This code more than size of struct.

    And, as I understand, after apdate for another firmware, this code also changed. But when update done, this part of code doesn't updated and programm crushed. and than reboot.

    Therefore - no problems with encript and CRC.

    How to say to Keil that don't need to add any code to the end of structure?

Related