NRF DFU HARDWARE VERSION reply not working as expected

RE: NRF DFU HARDWARE VERSION reply not working as expected

Navin — Tue, 16 Jun 2020 08:15:28 GMT

Hi Hung Bui,

I found the problem.

Although the hardware structure was modified to accommodate HW Version, it was not serialized.

case NRF_DFU_OP_HARDWARE_VERSION:
            {
                index += uint32_encode(p_response->hardware.part,                 &p_serialized_rsp[index]);
                index += uint32_encode(p_response->hardware.variant,              &p_serialized_rsp[index]);
                index += uint32_encode(p_response->hardware.memory.rom_size,      &p_serialized_rsp[index]);
                index += uint32_encode(p_response->hardware.memory.ram_size,      &p_serialized_rsp[index]);
                index += uint32_encode(p_response->hardware.memory.rom_page_size, &p_serialized_rsp[index]);
                index += uint32_encode(p_response->hardware.hw_version, 		  &p_serialized_rsp[index]);
            } break;

This is the reason it was missing on the response from the slave.

Thank you for your response!

Best regards,

Navin

RE: NRF DFU HARDWARE VERSION reply not working as expected

Hung Bui — Mon, 15 Jun 2020 14:02:56 GMT

Hi Navin,

I am not sure I fully understand what you wrote here:

I have made the changes as seen in the code snippet. But I receive just the 32 bytes before modification. Any changes to these variables is reflected in the output that is read.

The problem is when I add an extra uint32_t variable, it doesn't reply!

So what exactly happened after you add the uint32_t variable in ? it didn't reply or you still receive the 32bytes before modification ?

Could you try putting a log or debug the bootloader to see what is used in p_req->callback.response(&response, p_req->p_context); call ? To check if the hardware version is included ?
If you capture an UART trace, what would you see in the trace ? Is there any chance that the hardware version is replied but the DFU master didn't parse it ?