Not sure if it's the right .zip file format

[Matze]

Hello,

I'm trying to update an application with a dual bank over BLE, but first I wanted to try on the given examples so I'm sure that I'm creating the .zip files the right way.

I'm useing the nRF51422 uController (pca10028) with SDK 11, the s130 Softdevice and nRFutill 0.5.2.

These are the steps I take:

- First I use nRFgo Studio to program the SoftDevice.

- Then I use Keil uVision5 to load the given dfu_dual_bank_ble_s130_pca10028.uvprojx (path: C:\nRF5_SDK_11.0.0_89a8197\examples\dfu\bootloader\pca10028\dual_bank_ble_s130\arm5_no_packs) file on the uController.

- Then I use the cmd to navigate to my .hex target (e.g. C:\nRF5_SDK_11.0.0_89a8197\examples\peripheral\blinky_freertos\hex\blinky_FreeRTOS_pca10028) and build a .Zip file with nrfutil dfu genpkg --application app.hex --dev-type 1 --dev-revision 3 --application-version 2 --sd-req 0x80 app_dfu_package.zip (I allready tried it without --dev-type, --dev-revision, --application-version and --sd-req, because I'm not sure if eim correct with dev-type and dev-revision).

- Afert that I transfer the .zip file to my smart Phone, connect to the uController with nRF Connect and upload the application with the dfu button where I select the .zip option.

The .zip file is accepted and uploaded to the uController, but after that the uController doesn't do anything. It should use LED 1 & 2 and let them blink but everything (except LED5) is dark.

When I tried this with C:\nRF5_SDK_11.0.0_89a8197\examples\dfu\ble_dfu_send_hex\test_images_update_nrf51\dfu_test_app_hrm_s130.hex and the allready given .zip file both worked the same.

Where did it go wrong?

[Einar Thorsrud]

The IRAM settings for the application is the same regardless if you use a bootloader or not. However, you need to adjust the IROM size so that it does not overlap with the bootloader. I expect you would have seen it during the initial programing if this was a problem.

How have you confirmed that the application is not started? The legacy bootloader in SDK 11 can be tricked to think that there is a valid application by setting setting the valid flag from a debugger "nrfjprog --memwr 0x3Fc00 --val 1". Using this the bootloader should always start the application, so if it still does not work then the error happens in the application.

Can you do some debugging in your application, starting at the beginning of main() to verify whether it is started or not? Could it be that the bootloader does not disable the 32 kHz clock properly, and that it causes problems for FreeRTOS in some way?