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

DFU over UART: Response code Invalid Object (NRF528240)

Hello Everyone,

Struggling with evaluation of Secure DFU over UART lines. I used the sample project "Secure DFU Bootloader over Serial Link (UART/USB) ", during the previous verification phase of two-wire DFU mechanism. My goal is to implement perform firmware upgrade where DFU mode is triggered by assertion any GPIO pin to low level. Machanism that is described in guide https://infocenter.nordicsemi.com/index.jsp worked perfect some time but now im taking an error: Response Code InvalidOblject.

I'm performing next sequence when try download the code:

1. clean whole chip using nrfGO studio (sometimes nrfjprog --recover, nrfjprog --eraseall)

2. Flash the softdevice.hex using nrfGO Studio (or nrfjprog --reset --program  softdevice_s140.hex --family NRF52 --sectoranduicrerase)

3. Program the bootloader into Eclipse IDE (i'm using GCC based toolchain).

4. Press button 4 and press reset button to enter the bootloading mode

5. nrfutil dfu serial -pkg hrs_application_s140.zip -p COM18 (COM18 is replaced with another number when another evaluation kit is used)to download code

This sequence of steps gave me the have always lead to successful firmware download. There is one thing more that make me more confusing: if i try to download the code using referent  bootloader_secure_uart_debug_without_bonds_mbr.hex , firmware upgrade over the UART is alwaus possible doing nrfutil dfu serial -pkg hrs_application_s140.zip -p COM18 command!

When try to debug the code i'm getting  NRF_DFU_EVT_DFU_FAILED.

I have sense that I have problem with the tools.

What can be the problem? Do I miss something to do or the problem is another nature?

P.S. Once i try to flash mbr.hex but it didnt gave me result.

Screeming for help please!

Parents
  • Hello,

    From your numbered points, I don't see what the problem is. Is there any problem here?

    Regarding debugging:

    The issue here is that when you do a DFU using a bootloader, the bootloader will verify that the application is valid, and store this this information based on the application image in a bootloader settings page.

    The issue when you are debugging is that the IDE will upload a copy of the image. In theory this should work fine if you don't change anything in the application that you just uploaded with DFU, but it turns out it is a problem after all. The issue is that the different compilers uses different padding for variables shorter than 32 bits. Some uses 0's and some uses 1's. This changes the CRC of the application, and if the application is updated, it may corrupt the CRC check stored in the bootloader settings.

    If you want to debug your application while you use bootloaders, you should use the debug project folders for the bootloader: pca10056_uart_debug. This doesn't check the CRC of the application, and debugging, which will update the application and corrupt the CRC will still work.

    Best regards,

    Edvin

Reply
  • Hello,

    From your numbered points, I don't see what the problem is. Is there any problem here?

    Regarding debugging:

    The issue here is that when you do a DFU using a bootloader, the bootloader will verify that the application is valid, and store this this information based on the application image in a bootloader settings page.

    The issue when you are debugging is that the IDE will upload a copy of the image. In theory this should work fine if you don't change anything in the application that you just uploaded with DFU, but it turns out it is a problem after all. The issue is that the different compilers uses different padding for variables shorter than 32 bits. Some uses 0's and some uses 1's. This changes the CRC of the application, and if the application is updated, it may corrupt the CRC check stored in the bootloader settings.

    If you want to debug your application while you use bootloaders, you should use the debug project folders for the bootloader: pca10056_uart_debug. This doesn't check the CRC of the application, and debugging, which will update the application and corrupt the CRC will still work.

    Best regards,

    Edvin

Children
No Data
Related