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.

[Matts]

Regarding the debugger, I noticed that with non-softdevice linkerfile the debugger works OK. The linker file style has changed pretty dramatically from SDK 12, so perhaps there's some setting that should be different. Also noticed that with the problematic linker file the debugger actually stopped at start of main, however it didn't just show the source code (just disassembly).

I'll try the now the fresh SDK, but I don't expect it to make much difference. There wasn't any changes in the example images before. I only generated the new key, but I even skip that.

[Matts]

No difference. My process below:

0. erase the flash of the device:

nrfjprog --eraseall -f nrf52

1. Build the bootloader without generating any keys.

2. go to _build and flash only the bootloader:

nrfjprog --reset --program nrf52832_xxaa_mbr.hex --family NRF52

3. go to nRF5_SDK_15.2.0_9412b96/examples/dfu/secure_dfu_test_images/uart/nrf52832 and try to do the dfu:

nrfutil dfu serial -pkg blinky_mbr.zip -p /dev/ttyACM0

File "/usr/local/lib/python2.7/dist-packages/nordicsemi/dfu/dfu_transport_serial.py", line 211, in open
raise NordicSemiException("No ping response after opening COM port")
pc_ble_driver_py.exceptions.NordicSemiException: No ping response after opening COM port

**********************'

BTW: Is there any example of the application with the booloader? I'm expecially interested in linker file, as one would assume there needs to be space reserved also for the bootloader.

[Hung Bui]

Hi Matts, 

Could you let me know how did you have the nrf52832_xxaa_mbr.hex file ? Did you combine the bootloader with the mbr ? If not, you would need to flash the mbr hex file first then flash the bootloader. The precompiled hex file we provided, we already added the mbr in, but not the one you compile on your own. 

The blinky mbr is a good example to be used to test the UART DFU. 

If you use the softdevice, there isn't any thing need to be changed in the application linker . The softdevice also included the MBR inside. For application that doesn't use softdevice , and was not made to be used with MBR you need to move the start address to address 0x1000 , please refer to the blinky mbr project example. 

Attached is the precompiled files come with the SDK I used and it worked fine for me here. I assume you have a PCA10040.
secure_bootloader_uart_mbr_pca10040_debug.hex

blinky_mbr.zip