nRF5_SDK_15.2 UART DFU problems

[Matts]

Hi.

We are on early phases of getting UART DFU support for our product. However I seem to run into communication issue with the bootloader even with the examples provided in the SDK.

The device seems to enter DFU mode OK (I can see the LEDs 1 and 4 to light up and sometimes even 1 and 2), however the nrfutil reports either "Serial port could not be opened on {0}" or "No ping response after opening COM port".

My test procedure with the examples (nRF5_SDK_15.2.0_9412b96/examples/dfu/secure_dfu_test_images/uart/nrf52832):

1. nrfjprog --eraseall -f nrf52

2. nrfjprog --reset --program mbr.hex --family NRF52 --sectorerase

3. nrfjprog --reset --program bootloader_secure_uart_debug_without_bonds_mbr.hex --family NRF52 --sectoranduicrerase

After rebooting the device I can see the leds 1 and 4 light up.

After that:

4. nrfutil dfu serial -pkg blinky_mbr.zip -p /dev/ttyACM0 (-b 115200 -fc 1 tested also with these, no difference)

My setup:

Ubuntu 16.04 LTS

SEGGER J-Link Commander V6.40 

nrf52832 (pca10040):

Firmware: J-Link OB-SAM3U128-V2-NordicSemi  compiled Jul 12 2018 11:44:4Hardware version: V1.00
S/N: 682270901
VTref=3.300V

nrfutil version
nrfutil version 4.0.0

python --version
Python 2.7.12

nrfjprog --version
nrfjprog version: 9.8.1
JLinkARM.dll version: 6.40

GNU_INSTALL_ROOT ?= /usr/local/gcc-arm-none-eabi-5_2-2015q4/bin/
GNU_VERSION ?= 5.2.1
GNU_PREFIX ?= arm-none-eabi

******************************************************

As a separate question regarding the bootloader and regular app without any support for bootloader:

Should I be able to have bootloader in the mix and the application should run normal? I mean I've tried with the combined image and the application doesn't start. I don't mind at this phase that I cannot enter the DFU mode from button, etc, but I would like to have the DFU bootloader in the mix and run the app.

My process for the image was:

1. build bootloader

2. Build app
3. goto bootloader _build
4. nrfutil settings generate --family NRF52 --application /path/to/app/_build/nrf52832_xxaa.hex --application-version 0 --bootloader-version 1 --bl-settings-version 1 setting.hex

5. mergehex -m nrf52832_xxaa_mbr.hex setting.hex -o bootloader_and_setting.hex
6. mergehex -m /path/to/app/nrf52832_xxaa.hex bootloader_and_setting.hex -o app_bootloader_and_setting.hex
7. mergehex -m nRF5_SDK_15.2.0_9412b96/components/softdevice/s132/hex/s132_nrf52_6.1.0_softdevice.hex app_bootloader_and_setting.hex -o sd_app_bootloader_and_setting.hex
8. nrfutil pkg generate --hw-version 52 --application-version 1 --application sd_app_bootloader_and_setting.hex --sd-req 0xAF --key-file private.key app_dfu_package.zip
9. nrfjprog --reset --program sd_app_bootloader_and_setting.hex --family NRF52 --sectoranduicrerase

Does this make any sense? My linker memory table looks like:

MEMORY
{
FLASH (rx) : ORIGIN = 0x26000, LENGTH = 0x5a000
RAM (rwx) : ORIGIN = 0x20002218, LENGTH = 0xdde8
}

Rest of it is pretty much right off the hrs example if I recall correctly (we update from SDK 12.xx recently so I had to update the linker file also).

[Hung Bui]

Hi Matts, 

If the bootloader running correctly , you should see LED 1 and LED3 turned on. Please try to debug and see why LED4 turned on ? Usually it's controlled inside dfu_observer()

I would suggest to try again with a fresh copy of the SDK.

In addition, have you tried to test the UART communication between  the board and your pc ? 

Regarding your second question, you can combine them, but not at step 8. When you generate image, you can't use the merged image. You should use the original application /bootloader /softdevice image. If you want to combine multiple images into one .zip file, you just use the nrfutil pkg generate to generate the package with multiple images. 

The combined image sd_app_bootloader_and_setting.hex , should be used to flash directly to the chip instead of using nrfutil to generate the .zip file. This is what usually used in production to save time. It's mentioned in the Appendix 1 in my blog here. 

[Matts]

Hi.

Traces run fine for application (not from bootloader).

Interestingly my debugger (I'm using eclipse) stopped working with the new SDK. I've previously used version was SDK 12 and it worked fine (and still does). However this one doesn't seem to be able to map to main() or any other source. I still can see the disassembly, but fe the debugger doesn't stop at main.

I'll try with fresh copy. Perhaps my debugger problems also are solved.