DFU CRC error

[dblasco]

Hi,

there are similar questions to this but I cannot solve my problem. I am trying to upload a new code using DFU by means of a smartphone (using nRF Connect) or PC (using Master Control Panel), without success. The code uploads correctly till 100% but then at the very end it gives me CRC error.

The very first time I upload a new code with DFU (after programming everything with a programmer of course) this does not happen, but if I try to do this more times (except if I upload the exact same code) this error happens.

I am using nrf51822, SDK 11, s130 (v2.0.1). The code is a modification of the ble_app_hrs_rscsc_relay code. The bootloader I use is also a modification of the bootloader dual_bank_ble_s130.

The modifications are done in a way that the main application writes in memory (using pstorage.h) a byte that the bootloader can read to go into DFU mode (therefore the bootloader includes pstorage.h as well).

The .zip package is correctly generated (I asked this in a past question and it seemed ok).

Could someone help me?

Thank you very much

[Hung Bui]

Hi,

Just to clarify what you described,

1. You flash softdevice and flash bootloader

2. You upload the firmware 1 using the bootloader, it worked fine ?

3. You DFU update again the same firmware 1, it worked.

4. You update to firmware 2, it's failed.

5. With the same firmware 2, if you upload it when the chip is clean it worked ?

Note that by default the Bootloader was made so that the first programming is not by the programmer but by DFU.

If the CRC is not match, I would suggest to compare the image when you receive the firmware, what is the difference causing it doesn't match. (compare the image on an successful trial with an unsuccessful one)

[dblasco]

Not exactly.

1. I flash softdevice, bootloader AND firmware 1 and go DFU
2. I upload firmware 1 (or firmware 2) and it works
3. I DFU the firmware, it works
4. I upload firmware 1, it works (if previous was firmware 1 as well, if not it fails) OR I upload firmware 2, it fails (and from now on it will fail for all firmwares)

Both firmwares are equal except for a byte in the advertising packet (so I can know it is correctly updated). The results are the same changing the order of firmware 1 and 2.

[Hung Bui]

You must have modified the bootloader so that it accept the firmware on the first run.

As I suggest you need to look into the CRC calculation and check what cause the CRC mismatched.

You can also try to test with the default bootloader example. If the default bootloader works fine, then there must be something wrong with the modification of the bootloader.

[dblasco]

I am working with the default bootloader to check what is happening. May I ask what do you mean with checking the CRC calculation? How could I do this? When I get news I will tell you Thank you

[Hung Bui]

CRC check is done inside dfu_init_postvalidate() in dfu_init_template.c . It's where we calculated the image CRC and compare to the CRC sent in the init packet at the beginning of the DFU process. This to ensure the integrity of the image.