Hello, I would like to develop an automated tool for our production line to use to perform DFU on our nRF52832 system. Is it possible to communicate with the nRF52 Dev kit using serial?
Hello, I would like to develop an automated tool for our production line to use to perform DFU on our nRF52832 system. Is it possible to communicate with the nRF52 Dev kit using serial?
Hello,
Are you using the nRF5 SDK? In that case, nrfutil (nRF Util for nRF5 SDK) should be the right tool for this. It is a command line tool that can be used to perform OTA and serial DFU. For OTA DFU it needs a separate DK/Dongle board for BLE connectivity.
Best regards,
Vidar
Thank you for the suggestion, I have been using python to run nrfutil command line tools for a while with relative success.
However, I find the DK board to be a bit flakey. Sometimes the connection is inexplicably lost, and sometime it seems that the board has lost its programming and needs to be reprogramed. I use nRF Connect to program the DK with the BLE firmware, but I don't want to ask our operators on the production line to do a task like this.
Where could I find the BLE hex file for the dev board? If I had that, I could use python to automatically reprogram the board if there is ever an issue
Hello,
The nrfutil dfu command has an optional argument called '--flash_connectivity ' to automatically flash the connectivity FW. You can also find the connectivity FW hex in the Github repo at: https://github.com/NordicSemiconductor/pc-ble-driver/blob/v4.1.4-hex/hex/sd_api_v5/connectivity_4.1.4_1m_with_s132_5.1.0.hex.
~$ nrfutil nrf5sdk-tools dfu ble --help Usage: pc_nrfutil_legacy_v6.1.7 dfu ble [OPTIONS] Perform a Device Firmware Update on a device with a bootloader that supports BLE DFU. This requires a second nRF device, connected to this computer, with connectivity firmware loaded. The connectivity device will perform the DFU procedure onto the target device. Options: -pkg, --package FILE Filename of the DFU package. [required] -ic, --conn-ic-id [NRF51|NRF52] Connectivity IC family: NRF51 or NRF52 [required] -p, --port TEXT Serial port COM port to which the connectivity IC is connected. -cd, --connect-delay INTEGER Delay in seconds before each connection to the target device during DFU. Default is 3. -n, --name TEXT Device name. -a, --address TEXT BLE address of the DFU target device. -snr, --jlink_snr TEXT Jlink serial number for the connectivity IC. -f, --flash_connectivity Flash connectivity firmware automatically. Default: disabled. -mtu, --att-mtu INTEGER RANGE ATT MTU. Maximum ATT packet size for BLE transfers. Accepted values in range [23, 247]. Default is 247. Note: Failing DFU transmissions can in some cases be solved by setting a lower mtu. [23<=x<=247] --help Show this message and exit.
mikefraguglia said:However, I find the DK board to be a bit flakey. Sometimes the connection is inexplicably lost, and sometime it seems that the board has lost its programming and needs to be reprogramed. I use nRF Connect to program the DK with the BLE firmware, but I don't want to ask our operators on the production line to do a task like this.
It's strange if the connectivity FW gets erased. If the communication is unstable you may want to try disabling the Mass storage class on the J-Link interface chip: https://docs.zephyrproject.org/latest/develop/flash_debug/nordic_segger.html#disabling-the-mass-storage-device-functionality. Alternatively, you can try using the nRF52840 Dongle. The dongle does not use the Jlink serial bridge but instead uses the USB interface exposed by the nRF52840.
Including '-f' in the DFU command is an excellent and simple safeguard.
I will try out the nRF52840 dongle as well.
Thank you!
Including '-f' in the DFU command is an excellent and simple safeguard.
I will try out the nRF52840 dongle as well.
Thank you!