FUOTA(Firmware update over the air) of Nordic controller NRF52840 using Azure as host.

[rajAsthana]

I want to perform FUOTA(Firmware update over the air) for my Nordic controller NRF52840 using Azure as host. 

Please suggest how to do this .

[rajAsthana]

Hi Einar ,

As suggested in the link I disabled the fc(flowcontrol), But still I am facing the same issue, Below is the command & log I am getting atfer issuing command for serial DFU:

Command issued: 

nrfutil dfu serial -pkg hrs_application_s140.zip -p COM19 -b 9600 -fc 0

-----------------------------LOG_START--------------------------------

2020-09-22 03:33:13,686 No trigger interface found for device with serial number: 6&2d471516&0&4, Product ID: 0x7523 and Vendor ID: 0x1A86

Traceback (most recent call last):
File "c:\users\raj\appdata\local\programs\python\python38-32\lib\runpy.py", line 194, in _run_module_as_main
return _run_code(code, main_globals, None,
File "c:\users\raj\appdata\local\programs\python\python38-32\lib\runpy.py", line 87, in _run_code
exec(code, run_globals)
File "C:\Users\raj\AppData\Local\Programs\Python\Python38-32\Scripts\nrfutil.exe\__main__.py", line 7, in <module>
File "c:\users\raj\appdata\local\programs\python\python38-32\lib\site-packages\click\core.py", line 829, in __call__
return self.main(*args, **kwargs)
File "c:\users\raj\appdata\local\programs\python\python38-32\lib\site-packages\click\core.py", line 782, in main
rv = self.invoke(ctx)
File "c:\users\raj\appdata\local\programs\python\python38-32\lib\site-packages\click\core.py", line 1259, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "c:\users\raj\appdata\local\programs\python\python38-32\lib\site-packages\click\core.py", line 1259, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "c:\users\raj\appdata\local\programs\python\python38-32\lib\site-packages\click\core.py", line 1066, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "c:\users\raj\appdata\local\programs\python\python38-32\lib\site-packages\click\core.py", line 610, in invoke
return callback(*args, **kwargs)
File "c:\users\raj\appdata\local\programs\python\python38-32\lib\site-packages\nordicsemi\__main__.py", line 1055, in serial
do_serial(package, port, connect_delay, flow_control, packet_receipt_notification, baud_rate, serial_number, True,
File "c:\users\raj\appdata\local\programs\python\python38-32\lib\site-packages\nordicsemi\__main__.py", line 970, in do_serial
dfu.dfu_send_images()
File "c:\users\raj\appdata\local\programs\python\python38-32\lib\site-packages\nordicsemi\dfu\dfu.py", line 127, in dfu_send_images
self._dfu_send_image(self.manifest.application)
File "c:\users\raj\appdata\local\programs\python\python38-32\lib\site-packages\nordicsemi\dfu\dfu.py", line 88, in _dfu_send_image
self.dfu_transport.open()
File "c:\users\raj\appdata\local\programs\python\python38-32\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

-------------------------- LOG_END --------------------------------

For reference I have attached my hardware connections diagram & snapshot of Device Manager  on my pc.

I am using USB to TTL convertor to connect my board to my PC & the com generated is COM19,Connection details are listed below

Board (GND) <---> USB to TTL convertor (GND) Brown wire

Board(Tx(pin no 6))  <---> USB to TTL convertor (RX)  Red wire

Board(Rx(pin no 8))  <---> USB to TTL convertor (TX)  Blue wire

[Einar Thorsrud]

Hi,

There may be an issue with nrfutil, as you should not normally get "No trigger interface found" for serial DFU, as that is USB specific (where there is a USB DFU trigger mechanism). I do not believe that is the root cause of the problem, though. It looks like there is communication issues, so I wonder if the nRF device is in bootloader/DFU mode?

• Can you confirm that the nRF is in bootloader mode, for instance using some leds in the bootloader or also using the debug bootloader with RTT logging?
• Can you confirm that the UART communication is working normally, when not in the bootloader, so that we know that the HW configuration and USB-UART bridge etc. is working?
• Have you configured the bootloader UART in the same way as the application where you have (hopefully) verified that the setup works? (specifically the pin assignments and baud rate in sdk_config.h, which should be the same in the bootloader and application).