Problem jumping to application in serial DFU

[Bert]

I am having a strange issue with the serial DFU in SDK 11, s132v2, specifically running either dfu_dual_bank_serial or dfu_single_bank_serial. My goal is to simply get the demo up and running, but I seem to get stuck when the bootloader tries to jump to the application. I followed these steps per docs, in my case:

1. Open nRFGoStudio and flash s132 soft device from SDK/components/softdevcie/s132/hex.
2. Compile/run dfu_single_bank_serial on the nRF52832 target.
3. Put target into bootloader mode
4. Open nRFGoStudio and navigate to the bootloader upload mechanism, using SDK/examples/dfu/hci_dfu_send_hex/test_images_single_bank_update_nrf52/dfu_test_app_hrm_s132.hex as input. Keeping default baud and flow control.

After about 40 seconds, nRFGoStudio reports back to let me know the upload was successful, the nRF52 then jumps into this block:

if (bootloader_app_is_valid(DFU_BANK_0_REGION_START) && !bootloader_dfu_sd_in_progress())
{
    // Select a bank region to use as application region.
    // @note: Only applications running from DFU_BANK_0_REGION_START is supported.
    bootloader_app_start(DFU_BANK_0_REGION_START);
}

As soon as bootloader_util_reset executes, as part of bootloader_app_start, the program halts. IAR displays the following warning:

“The stack pointer for stack 'CSTACK' (currently 0x20004920) is outside the stack range (0x20002C30 to 0x20003430)”

Now, the warning is self-explanatory, but this demo presumably works for other people, and I’m curious if I have done something in a prior step to cause this. My initial reaction was to play with the RAM start/stop positions in the linker file, but it has no impact as I am continuously hitting this issue at the same stack range. For reference, here is my configuration:

define symbol __ICFEDIT_intvec_start__ = 0x7a000;
/*-Memory Regions-*/
define symbol __ICFEDIT_region_ROM_start__ = 0x7a000;
define symbol __ICFEDIT_region_ROM_end__   = 0x7dfff;
define symbol __ICFEDIT_region_RAM_start__ = 0x20002c00;
define symbol __ICFEDIT_region_RAM_end__   = 0x20007f7f;
export symbol __ICFEDIT_region_RAM_start__;
export symbol __ICFEDIT_region_RAM_end__;
/*-Sizes-*/
define symbol __ICFEDIT_size_cstack__ = 0x800;
define symbol __ICFEDIT_size_heap__   = 0x200;

One important thing to note, with this same nrf52 device, I am able to run other examples within SDK11. For example, I ran the UART loopback example as a test. Also, I did turn on debug info for a couple runs, which is how I found the CSTACK error above after the bootloader would try to jump to the application. Regardless if debugging is on or off, the application still locks up at the same point.

Any thoughts?

In the meantime I am going to downgrade nrfutil to 0.5.2 per docs, as that contains the legacy version. Using nRFGoStudio(1.21.2.10) instead of directly using nrfutil is the one deviation I've made from the instructions, so I'll go back with nrfutil 0.5.2 and try again.

[Bert]

After digging a bit deeper, I started considering the package itself, namely dfu_test_app_hrm_s132.zip. The docs state that after unwrapped, the manifest file can be viewed. This manifest contains the following JSON:

{
    "manifest": {
        "application": {
            "bin_file": "dfu_test_app_hrm_s132.bin",
            "dat_file": "dfu_test_app_hrm_s132.dat",
            "init_packet_data": {
                "application_version": 4294967295,
                "device_revision": 65535,
                "device_type": 65535,
                "firmware_crc16": 37832,
                "softdevice_req": [
                    121
                ]
            }
        },
        "dfu_version": 0.5
    }
}

The attribute of interest here is sotfdevice_req. I found a mapping on the forum, which connects softdevice FWID to versions. In this case, dfu_test_app_hrm_s132 requires softdevice id 121, which maps to 0x0079. With that said, prior to uploading over DFU, I checked what the FWID was for the softdevice that ships with SDK11:

$ nrfjprog --memrd 0x300C
0x0000300C: FFFF0081

Note that the versions do not match. Long story short, the SDK ships with S132 v2.0.0 but that test hex file was compiled against S132 v2.0.0-7.alpha. After verifying this, I ran a simple test, compiling the ble_blinky example against S132v2, and requiring that particular softdevice during package generation:

nrfutil dfu genpkg --application blinky.hex --sd-req 0x81 blinky.zip

And uploaded

nrfutil dfu serial --package blinky.zip --port /dev/ttyS3 --baudrate 38400

Worked like a charm!

This is not an issue with Nordic per say, as those test files probably aren't maintained. It was more of an oversight on my end as I should have created my own hex opposed to using the sample hex in hci_dfu_send_hex.

Anyway, hopefully this will help someone else down the road. Maybe someone from Nordic can verify the findings as a sanity check.