DFU SDK13. Problems with update. Starnge behavior.

[Mikhail]

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?

[Vidar Berg]

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.

 

[Mikhail]

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 ()?

[Vidar Berg]

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. 

[Mikhail]

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.   

[Mikhail]

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?

[Mikhail]

For berret understand problem, I type real code:

 volatile PASSKEY_CONTEXT pass __attribute__((section(".ARM.__at_0x72500"))) =
{
	.passkey_length 			= 6, 	.passkey 				= "123456", 
};

But in the .hex I get:

:102500000631323334353600000000000000000090
:10251000011022011A4002B11BFFFF1401619461F6
:102520008A028B893D0C012E0C10181818122901F3
:10253000014E1220027540C490D00314E1360223EC
:0425400003FF000095
:040000050001F20103
:00000001FF

What the final lines? Suppose, this is part of firmware.