Secure Bootloader with DFU will not start Valid Application

RE: Secure Bootloader with DFU will not start Valid Application

Hung Bui — Thu, 23 Nov 2017 15:53:28 GMT

@Dev: The bootloader has been tested before release, and many users used it but didn't have the same issue.

It's very strange that you tried with fresh SDK and still have the issue. Maybe you can send us your bootloader, your .zip (with blinky application) that we can test here.

RE: Secure Bootloader with DFU will not start Valid Application

Dev — Thu, 23 Nov 2017 15:15:45 GMT

I have come to the following conclusions:

The secure BL requires that an application be sent twice before it runs. There is a problem in the BL that mixes up the banks and believes that the app is no correct after DFU. Sending the app again places it in the other bank (0x1F000) and it runs just fine. This occurred with the HRM example, completely unchanged (using the test hex file).
Building a 'private' version of the BL and building HRM app with the private key works exactly like the example versions, it requires sending twice to work.
Debug text is not sent when the BL operates. The HRM app has debug output and it is not visible. This might explain why my app appeared not to work.
Having built an App with LED output and sent it (Twice), it runs.

This is all with the SDK downloaded clean.

I will now proceed to see what I can do about not having any debug text available although that is not critical - I can develop with a BL and only use the BL when doing DFU etc.

However, the issue with the BL, which seems to make errors with the banks etc. needs to be looked at, we require the newly-installed APP to run at startup. I assume I will have to invalidate the old App when installing the new one.

I suspect that I will have to download the Application and flash it, with settings, and then reset the device and make it enter the bootloader using the buttonless mechanism.

Thanks for your advice in any case.

RE: Secure Bootloader with DFU will not start Valid Application

Dev — Thu, 23 Nov 2017 14:04:24 GMT

My application works correctly without the BL, no problem.

I have tried flashing the BL, SD and the App and settings with no success.

It is already a simple application, it just prints Hello. I added a buzzer sound which works on our board only, but that also works no problem without the BL present.

I have now done the following to gain more information:

I have downloaded a new copy SDK13 to ensure any changes made locally are no longer present, because another dev worked on it before.
I built the secure BL, with only the following changes: a. Add the micro-ecc elements b. Add the required gcc settings to make it build c. Change the BL RAM settings and rebuild when the SD said they were not a match

I also have switched to the Nordic dev board to ensure there is no compatibility issue.

I flashed the BL+SD as before and used the Toolbox to send the HRM test application package to the device.

This flashed to 0x22000, it says but, after it completed, the debug said

:INFO:Running SD version check ============== :INFO:Successfully ran the postvalidation check! :INFO:Invalidating old application in bank 0. :DEBUG:Erasing old settings at: 0x0007f000 :DEBUG:Waiting for other flash operation to finish. :DEBUG:Waiting for other flash operation to finish. :DEBUG:Erasing: 0x0007f000, num: 1 :DEBUG:Writing 0x00000057 words :DEBUG:Writing settings... :DEBUG:Sending Response: [0x4, 0x1] :INFO:Inside main :DEBUG:In nrf_bootloader_init :DEBUG:In real nrf_dfu_init :DEBUG:running nrf_dfu_settings_init :DEBUG:Enter nrf_dfu_continue :DEBUG:Valid App :DEBUG:Enter nrf_dfu_app_continue :DEBUG:Erasing: 0x0001f000, num: 1 :ERROR:Invalid data during compare: target: 0x0001f000, src: 0x00022000 :DEBUG:Could not continue DFU operation: 0x0000000e

As you can see, it did not run.

I uploaded the app again without erasing anything and it flashed to 0x1f000 this time.

:DEBUG:Enter nrf_dfu_find_cache :DEBUG:Bank content :DEBUG:Bank type: 0 :DEBUG:Bank 0 code: 0x00: Size: 10328 :DEBUG:Bank 1 code: 0x01: Size: 37380 :DEBUG:No previous, using bank 0

Note: It did not see an app in bank 0 from before but it did see an app in bank 1

After DFU finished, the debug said:

:DEBUG:Sending Response: [0x4, 0x1] :DEBUG:In nrf_bootloader_init :DEBUG:In real nrf_dfu_init :DEBUG:running nrf_dfu_settings_init :DEBUG:Enter nrf_dfu_continue :DEBUG:Valid App :DEBUG:Enter nrf_dfu_app_is_valid :DEBUG:Return true. App was valid :DEBUG:Enter nrf_dfu_app_is_valid

###RTT Client: Connection closed by J-Link DLL. Going to reconnect. ###RTT Client: Connecting to J-Link RTT Server via localhost:19021 Connected. SEGGER J-Link V6.18 - Real time terminal output J-Link OB-SAM3U128-V2-NordicSemi compiled Jul 24 2017 17:30:12 V1.0, SN=682396899 Process: JLinkExe

And disconnected.

If I reset, it repeats:

But , checking with the Toolbox App, I see that it is running.

I will have to build my own version of the HRM App, with a private key and then move on to trying to see why my app cannot even send debug when the BL is present but works otherwise.

FYI, we have a large App (130k) running quite happily on our board, with debug etc.

There must be some clash with the App build and the BL build which prevents successful execution of the cut-down version. I cut it down to simplify the DFU development process.

Thanks for the info and I will post results, one way or the other

RE: Secure Bootloader with DFU will not start Valid Application

Hung Bui — Thu, 23 Nov 2017 13:20:50 GMT

Hi Dev,

Please clarify:

If you flash SD+BL then flash application + bootloader setting, would the application works ? Have you check if the application actually entered ? You can run a debugger and put a break point in the application code to check. Or you can first test with very simple application for example blinking LED, just for testing.
Have you tried to do DFU with BLE example in the SDK ble_app_hrs for example ?

I suspect that your application was actually updated properly and branched to successfully but when running it crashes for some reasons (something used by the bootloader and then the application also use and something wrong with the register cause an issue).

You can do "nrfjprog --readcode" to read the hex dump and then compare with when you flash SD+APP normally and see if there is anything different.

RE: Secure Bootloader with DFU will not start Valid Application

Dev — Thu, 23 Nov 2017 11:54:16 GMT

After more investigation I have found further issues with the BL.

The DFU shows text indicating that a given bank is being programmed...

:INFO:Valid Data Create :DEBUG:Erasing: 0x00022000, num: 1 :INFO:Creating object with size: 4096. Offset: 0x00000000, CRC: 0x00000000 :DEBUG:Sending Response: [0x1, 0x1] :INFO:Storing 256 B at: 0x00022000 :INFO:Storing 256 B at: 0x00022100 :INFO:Storing 256 B at: 0x00022200 :INFO:Storing 256 B at: 0x00022300 :INFO:Storing 256 B at: 0x00022400

and so on.

However, when I read the flash before and after the operation, it reads thus.

Before. nrfjprog -f nrf52 --memrd 0x22000 --w 8 --n 8 0x00022000: FF FF FF FF FF FF FF FF

nrfjprog -f nrf52 --memrd 0x1f000 --w 8 --n 8 0x0001F000: FF FF FF FF FF FF FF FF |........|

After: nrfjprog -f nrf52 --memrd 0x22000 --w 8 --n 8 0x00022000: FF FF FF FF FF FF FF FF |........|

nrfjprog -f nrf52 --memrd 0x1f000 --w 8 --n 8 0x0001F000: 10 B5 05 4C 23 78 33 B9 |...L#x3.|

The DFU plainly programmed the 0X1F000 address despite saying that it was programming the 0x22000 address.

RE: Secure Bootloader with DFU will not start Valid Application

Dev — Thu, 23 Nov 2017 10:38:55 GMT

Also. I added debug after the call to sd_softdevice_vector_table_base_set in nrf_bootloader_app_start and noticed that that call does not return.

So the problem would appear to be there rather than in the Application launch nrf_bootloader_app_start_impl itself.

I assume the program Hex file creates a vector table at the start address of an Application?

RE: Secure Bootloader with DFU will not start Valid Application

Dev — Thu, 23 Nov 2017 10:34:52 GMT

Of course, I am still looking at this and I have noted that the original question shows that the application is being flashed at 0x27000 and the Application is started at 0x1F000.

I have looked at the code in nrf_dfu.c and noticed that the code which checks for a valid application and then runs one has no idea about the dual-banl nature of the DFU code.

The nrf_dfu_init function always jumps to 0x1f000.

I amended this to jump to 0x27000, which is the actual address that gets programmed, bank 1.

Since I erased the flash using eraseall (and recover just in case), I am unsure why bank 1 is being chosen but the DFU finds an app at 0x1f000.

Anyway, programming at 0x27000 and then running at 0x27000 still doesn't work.

RE: Secure Bootloader with DFU will not start Valid Application

Dev — Wed, 22 Nov 2017 14:56:23 GMT

More information, which may be useful:

I merged a generated settings hex file with the application hex file.

If I flash the DFU BL and SD and then use nrfjprog to flash the application, the BL rejects the application with a CRC error.

:INFO:Inside main :DEBUG:In nrf_bootloader_init :DEBUG:In real nrf_dfu_init :DEBUG:running nrf_dfu_settings_init :DEBUG:Enter nrf_dfu_continue :DEBUG:Valid App :DEBUG:In weak nrf_dfu_enter_check :DEBUG:Enter nrf_dfu_app_is_valid :DEBUG:Return false in CRC :DEBUG:In nrf_dfu_transports_init :DEBUG:num transports: 1 :DEBUG:vector table: 0x00075000 :DEBUG:vector table: 0x00075000 :DEBUG:Error code - sd_softdevice_vector_table_base_set: 0x00000000 :DEBUG:Before SOFTDEVICE_HANDLER_APPSH_INIT :DEBUG:After SOFTDEVICE_HANDLER_APPSH_INIT :INFO:Error code - sd_ble_cfg_set: 0x00000000 :DEBUG:Enabling softdevice. :DEBUG:RAM start at 0x20002060. :DEBUG:Softdevice enabled :DEBUG:After nrf_dfu_transports_init :DEBUG:------- nrf_dfu_flash_init------- :DEBUG:Waiting for events

But, If I flash with the settings hex, the BL accepts the application:

Since the application was flashed at 0x1F000, I don't see why it will not run but I see no output.

Something I also noted was that using the BLE DFU, I see the application flashed to places other than 0x1F000, which would be fine since it is a twin bank BL (?)

However, the application is still started at 0x1F000, which cannot be right.

This occurs even if I have erased the flash previously.

... :INFO:Storing 256 B at: 0x0002eb00 :INFO:Storing 256 B at: 0x0002ec00 :INFO:Storing 256 B at: 0x0002ed00 :INFO:Storing 80 B at: 0x0002ee00 :DEBUG:Received calculate CRC ... :DEBUG:Writing settings... :DEBUG:In weak nrf_dfu_enter_check :DEBUG:Enter nrf_dfu_app_is_valid :DEBUG:Return true. App was valid :DEBUG:Enter nrf_dfu_app_is_valid :DEBUG:Return true. App was valid :DEBUG:Jumping to: 0x0001f000