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

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

Parents
  • 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.

  • can you please guide on how to move the start address of the application to address 0x1000?

    I opened blinky_gcc_nrf52.ld file and changed flash starting address. earlier it was 0x00.I changed it to 0x1000

    MEMORY

    {

    FLASH (rx) : ORIGIN = 0x1000, LENGTH = 0x80000

    RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 0x10000

    }

    But it didn't work.

  • Hi Swanand,

    The easiest way to find out the different between a blank project and mbr project, I think, is to compare the .ld file and the Makefile.  You can use an editor tool for example Notepad++ with Compare plugin. 
    If you compare the blinky_gcc_nrf52.ld in the \blinky\pca10040\mbr with the one in \blinky\pca10040\blank you can find that the RAM need to be updated as well: 


    And in the make file, you would need to add   $(SDK_ROOT)/components/softdevice/mbr/headers \ into INC_FOLDERS. 

  • Hi,

    I opened segger embedded studio then go to the project and right clicked on options->select common->linker->selection placement macros-> change flash address to FLASH_START=0x1000 and FLASH_SIZE=0x79000 and it works. 

    Now I wanted to flash another zip file so I have taken uart example. I did the above changes and then build and run the code. This time the code did not work and if I revert back the changes then the code is working but if I create a zip file of that hex then the zip file is not working. 

  • Hi Swanand, 
    After you DFU update the application code. You can't just modify the code and flash again. The bootloader won't accept any change to the code without going through DFU. 
    This is to avoid the code being manipulated or tampered. It's called boot validation. By default it's done by calculating the CRC of the image. 


    You can turn boot validation off by modifying the bootloader. Please take a look at dfu_enter_check() , you can comment this out : 
    if (!app_is_valid(crc_on_valid_app_required()))
    {
    NRF_LOG_DEBUG("DFU mode because app is not valid.");
    return true;
    }

    But make sure to turn it back on when you finish with development. 

  • Hi,

    Thanks for your guidance. I am able to do dfu. I have updated 3 packages. But now I am facing issue

    I have taken blinky code and made a zip of it and flashed that code. it worked. Again I updated the blinky code, made another zip, and flashed it again(worked). Now I added button logic in blinky code and made 3rd zip & flashed (worked). the fourth time I added UART in the blinky code and flashed a zip file. this time zip is not working.

    If I erased all and then flashed mbr + 4th hex file(uart added file) it is working. But if I make a zip file of it, it is not working.

    Note: I have changed RAM_START=0x20000000 to RAM_START=0x20000008. UART code is not working at RAM_START=0x20000000

Reply
  • Hi,

    Thanks for your guidance. I am able to do dfu. I have updated 3 packages. But now I am facing issue

    I have taken blinky code and made a zip of it and flashed that code. it worked. Again I updated the blinky code, made another zip, and flashed it again(worked). Now I added button logic in blinky code and made 3rd zip & flashed (worked). the fourth time I added UART in the blinky code and flashed a zip file. this time zip is not working.

    If I erased all and then flashed mbr + 4th hex file(uart added file) it is working. But if I make a zip file of it, it is not working.

    Note: I have changed RAM_START=0x20000000 to RAM_START=0x20000008. UART code is not working at RAM_START=0x20000000

Children
  • 0564.test.rar

    Please find the attached zip file. I have created a zip file by using this hex.

  • Hi Swanand, 


    When you wrote "flash it" you meant program the application via programmer or you meant you did DFU update ? 
    I would assume what you meant by " this time zip is not working" it means the DFU update worked fine and you managed to update but it doesn't run. 

    In that case you may need to do debugging. You can debug and step in the code just like what you normally do. 
    If you see that you can not debug the code, it could be that the bootloader didn't run the application, then you need to step in the code of the bootloader and check why it doesn't jump to the application. You may need to use the debug version of the bootloader to step in the bootloader code. 

    What I want to say is that it's not a black box and you can just debug the bootloader and the application normally. 

  • Hello,

    Yes, the DFU update is working fine & it runs successfully.  I found that my 4th package is also working and running but I am not able to view data on a tera term(serial utility) which I send on uart(uart instance 1 configured in application).

    my understanding is that nrf52832 has only 1 uart peripheral. So we are doing dfu over uart in bootloader and the application also uses uart. Can I use uart in the application? 

    also If I erased all and then flashed mbr + uart hex file then I can see uart prints.

  • Hi Swanand, 


    They can share UART, the bootloader is not running when the application is running. 
    But you have to make sure you initialize UART properly in your application. Double check if you have configured everything correctly. The potential issue is that if the bootloader use UART the registers may be different from the reset value. 

Related