• State Verified Answer
  • Replies 16 replies
  • Subscribers 62 subscribers
  • Views 6600 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 116868
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Secure bootloader upload failed: UNKNOWN (8202)

Gordon

Hi,

I've been trying to integrate the secure bootloader witrh SDK12 into my device, which had been working fine with the old bootloader and SDK11.

I've swapped everything over, and finally got the bootloader to boot into my application. The only real gotcha was that the bootloader setting had changed, so if I just merged all the hex files it failed to load the application.

To fix that, I just removed the bootloder settings from 0x3F000 and tweaked the check in nrf_dfu_app_is_valid to allow the app even if bank_0.bank_code was 0. Is there a better way - like a way to build a hex file for the correct settings?

Anyway, with that change, and the bootloader running, I get upload failed: UNKNOWN (8202) when trying to upload from the Nordic Android app. The device itself has lit the LED showing that it's connected.

So how do I find out what Error 8202 means? I don't see any obvious mention of it (or 200A, the hex version) in the source.... And any thoughts on how it can be fixed? I figure if there was some version or encryption mismatch then it would have come up with a 'proper' error?

thanks!

  • 0

    No, the device is staying in bootloader mode(in fact you can reconnect). So the fact that bank_code is currently 0 won't be an issue, as all being well the bootloader should just upload the binary and then overwrite it?

  • 0

    8202 = 0x200A, which is NRF_ERROR_SOC_BASE_NUM+10... However there isn't one of those (only errors up to 9). Maybe it's something internal?

  • 0

    Ok, same error when using the pre-built DFU hex file. I don't seem to have the Nordic private key so I can't test uploading a properly signed ZIP, but I'd kind of hoped that if that were the problem there would have been a more helpful error message.

  • 0

    Hi Gordon, I'm not sure if this will help, but I had this exact issue until I removed the --debug-mode flag and specified actual version requirements during the creation of the init package.

  • 0

    Right, thanks to Bjørn's help outside the forum we've sorted this.

    It looks like 8202 is the Nordic App's error code for InvalidObject, which in turn means the package couldn't be verified, because of some key problem.

    You get much more information by trying to upload from your PC with

    nrfutil dfu ble -f -pkg you_package.zip

    In my case, the keys were fine. The issue was actually the compilation of micro-ecc, which requires the following definitions:

    -DuECC_ENABLE_VLI_API -DuECC_VLI_NATIVE_LITTLE_ENDIAN=1 -DuECC_SQUARE_FUNC=1 -DuECC_SUPPORTS_secp256r1=1 -DuECC_SUPPORT_COMPRESSED_POINT=0 -DuECC_OPTIMIZATION_LEVEL=3

    If you were using Nordic's provided toolchain you wouldn't have this, but I was building myself with GCC and Makefiles, so I didn't spot this buried in external/micro-ecc/nrf52_armgcc/armgcc/Makefile.

    Now when that is done, I succeeded in uploading one of the example hex files with the example public key, but I got OperationFailed when uploading my own file.

    It turns out that when making the package with nrfutil pkg generate you need to provide the correct hardware version --hw-version 52. I'd been using 1.

Related