pc_ble_driver_py.exceptions.NordicSemiException: No ping response after opening COM port

[swanand]

Hi all,

I am using nRF52832, nrfutil version 6.1.7 and nRF5_SDK_17.1.0_ddde560. I wanted to perform DFU over serial UART. I am not using a soft device. I have referred the following link 

https://devzone.nordicsemi.com/f/nordic-q-a/43698/bootloader-serial-dfu-without-softdevice-sdk-15#:~:text=start%20the%20DFU.-,As%20I%20understand%2C%20you%20wish%20to%20do%20a%20DFU%20without,to%20use%20the%20precompiled%20firmware.&text=The%20difference%20between%20the%20two,only%20requires%20for%20the%20bootloader

 When I try to run nrfutil dfu serial -pkg blinky_mbr.zip -p COM10 -b 115200 commands I get the following error. 

D:\nRF5_SDK_17.1.0_ddde560\examples\dfu\secure_dfu_test_images\uart\nrf52832>nrfutil dfu serial -pkg blinky_mbr.zip -p COM10 -b 115200
  [------------------------------------]    0%
Traceback (most recent call last):
  File "C:\Users\Lenovo\AppData\Local\Programs\Python\Python38\lib\runpy.py", line 194, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "C:\Users\Lenovo\AppData\Local\Programs\Python\Python38\lib\runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "C:\Users\Lenovo\AppData\Local\Programs\Python\Python38\Scripts\nrfutil.exe\__main__.py", line 7, in <module>
  File "C:\Users\Lenovo\AppData\Local\Programs\Python\Python38\lib\site-packages\click\core.py", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "C:\Users\Lenovo\AppData\Local\Programs\Python\Python38\lib\site-packages\click\core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "C:\Users\Lenovo\AppData\Local\Programs\Python\Python38\lib\site-packages\click\core.py", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "C:\Users\Lenovo\AppData\Local\Programs\Python\Python38\lib\site-packages\click\core.py", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "C:\Users\Lenovo\AppData\Local\Programs\Python\Python38\lib\site-packages\click\core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "C:\Users\Lenovo\AppData\Local\Programs\Python\Python38\lib\site-packages\click\core.py", line 760, in invoke
    return __callback(*args, **kwargs)
  File "C:\Users\Lenovo\AppData\Local\Programs\Python\Python38\lib\site-packages\nordicsemi\__main__.py", line 1073, in serial
    do_serial(package, port, connect_delay, flow_control, packet_receipt_notification, baud_rate, serial_number, True,
  File "C:\Users\Lenovo\AppData\Local\Programs\Python\Python38\lib\site-packages\nordicsemi\__main__.py", line 988, in do_serial
    dfu.dfu_send_images()
  File "C:\Users\Lenovo\AppData\Local\Programs\Python\Python38\lib\site-packages\nordicsemi\dfu\dfu.py", line 127, in dfu_send_images
    self._dfu_send_image(self.manifest.application)
  File "C:\Users\Lenovo\AppData\Local\Programs\Python\Python38\lib\site-packages\nordicsemi\dfu\dfu.py", line 88, in _dfu_send_image
    self.dfu_transport.open()
  File "C:\Users\Lenovo\AppData\Local\Programs\Python\Python38\lib\site-packages\nordicsemi\dfu\dfu_transport_serial.py", line 214, in open
    raise NordicSemiException("No ping response after opening COM port")
pc_ble_driver_py.exceptions.NordicSemiException: No ping response after opening COM port

[swanand]

Hello,

I am using Development Kit, nRF52832 

https://www.tme.com/in/en/details/nrf52-dk/development-kits-others/nordic-semiconductor/?brutto=1&currency=USD&gclid=CjwKCAjw__ihBhADEiwAXEazJqeXMXIDukWCs8SEZTjG3WnDB_F9ixCgIa37lCZRoxRPJQxvu8bN7BoCA50QAvD_BwE

I am able to run dfu code 1 time only. Now if I repeat the same steps then I get "No ping response error"

[swanand]

Do I need to flash the MBR hex file and output.hex file (bootloader + bootloader setting) every time whenever I want to do DFU?  

I am using mbr.hex file located at D:\nRF5_SDK_17.1.0_ddde560\examples\dfu\secure_dfu_test_images\uart\nrf52832

After nrfutil dfu serial -pkg my_blinky_mbr.zip -p COM10 -b 115200 -fc 0 command, I am getting the following response

C:\Users\Lenovo\Desktop\DFU_PKG\test1>nrfutil dfu serial -pkg my_blinky_mbr.zip -p COM10 -b 115200 -fc 0
[####################################] 100%
Device programmed.

C:\Users\Lenovo\Desktop\DFU_PKG\test1>

But still LEDs are not blinking.

[Hung Bui]

Hi Swanand, 
No you don't need to re-flash MBR and bootloader very time you want to do DFU. However, you need to make sure the device is in DFU mode when do DFU. By default if you have done a DFU update, to be able to put the device to DFU mode again you need to hold button 4 and do a reset/power reset. 

Please don't test with bootloader setting. You don't need bootloader setting to test DFU update. 

Have you tried to test with the bootloader and the image in secure_dfu_test_images instead of your application and bootloader ? 
You should see the LED blink after you update the blinky_mbr.zip . If it work, try to update the second time by putting the device in DFU mode again. ( You should see LED1 and LED4 lid)

[swanand]

Yes, I have tried to test with the bootloader and the image in secure_dfu_test_images. it is working fine. But when I create my own packet and run it, that time it shows successful but the LEDs are not blinking. I am doing the following steps.

1.
nrfutil.exe keys generate private.key

2.
nrfutil keys display --key pk --format code private.key --out_file public_key.c

3.
nrfutil pkg generate --hw-version 52 --application-version 1 --application blinky_pca10040.hex --key-file private.key --sd-req 0 my_blinky.zip

4.
build uart secure bootloader code (Using embedded segger studio)

5.
nrfutil settings generate --family NRF52 --application blinky_pca10040.hex --application-version 1 --bootloader-version 2 --bl-settings-version 1 settings.hex

6.
nrfutil settings display settings.hex

7.
mergehex --merge settings.hex secure_bootloader_uart_mbr_pca10040.hex --output output.hex

8.
flash following hex files (using nRF connect)
mbr.hex
output.hex 

9.
nrfutil dfu serial -pkg my_blinky.zip -p COM10 -b 115200 -fc 0

[Hung Bui]

Please don't test with mergehex or settings until you have DFU working. 
Please do this: 
1. Flash MBR + your blinky example . Make sure LEDs blink. 

2. Erase all

3. Rebuild the bootloader with your public key. 

4. Flash the bootloader and the MBR. Make sure the LED1&4 turn on showing it's in debug mode. 

5. Generate the .zip image from your application and your private key

6. Do DFU update. Verify that LED blinks.

7. Press and hold button 4 when reset the board, verify that it enters DFU mode. 

8. Do another DFU update. 

[swanand]

Hi,

Thanks for your reply. It is working with pca10040_uart_debug but not working with pca10040_uart. How can I run with pca10040_uart?

I have another doubt I program secure_bootloader_uart_mbr_pca10040_debug.hex, mbr.hex, and then generate the package, at that time if I use blinky_pca10040_mbr.hex to generate the package then after dfu, the new image code is working fine but if I generate a zip file with normal blinky_pca10040.hex file then it shows Device programmed but that package is not working (zip file code is not working. LEDs are not blinking). 

[Hung Bui]

Hi Swanand, 

The tricky part when you test with the _debug version and non _debug version is that you would need to do an eraseall before you test with each of them. The reason is that they require the UICR to be re-written because of different start address of the bootloader. 

If you do a eraseall/recover before testing it should be fine. 

You should use the \examples\peripheral\blinky\pca10040\mbr if you plan to do DFU. 

It's because when you flash bootloader and MBR for DFU, the MBR is located at address 0x00000000 to address 0x0001000. Because of that the application should start from 0x00001000 instead of 0x00000000. So you need to build the application that start from this address, not the one start from 0x00. 
If you DFU an application that supposed to run at 0x00 (the normal blinky) it won't work at address 0x1000. 

So if you plan to move to something else, for example uart example or rtc example, you would need to do the same modification to move the start address of the application to address 0x1000.