Dump stock firmware

[kelchm]

As a first step, we should ensure that it is possible to dump the stock firmware of the device.

[kelchm]

I've made some progress here, though I've not had a chance to write up instructions within the wiki.

• Header J5 breaks out all the connectors we need to program the NRF52.
• I've been able to use a Segger J-Link to dump the firmware using either nRF Connect or nrfjprog. Oddly, the hex files produced by both of these approaches are not identical.
  • cgg1-stock-1.1.2_0020.hex.zip (dumped with nrfjprog)
  • nrf-cgg1-stock-1.1.2_0020.hex.zip (dumped with nrfconnect)

[kelchm]

Thanks to @atc1441 for taking an initial look at the dumps shared above as well as sharing a quick tip on OpenOCD.

> flash banks
#0 : nrf52.flash (nrf5) at 0x00000000, size 0x00080000, buswidth 1, chipwidth 1
#1 : nrf52.uicr (nrf5) at 0x10001000, size 0x00001000, buswidth 1, chipwidth 1

> flash read_bank 0 cgg1-bank0-stock-1.1.2_0020.bin
wrote 524288 bytes to file cgg1-bank0-stock-1.1.2_0020.bin from flash bank 0 at offset 0x00000000 in 9.803120s (52.228 KiB/s)
> flash read_bank 1 cgg1-bank1-stock-1.1.2_0020.bin
wrote 4096 bytes to file cgg1-bank1-stock-1.1.2_0020.bin from flash bank 1 at offset 0x00000000 in 0.077255s (51.777 KiB/s)

cgg1-bank0-stock-1.1.2_0020.bin.zip cgg1-bank1-stock-1.1.2_0020.bin.zip

--

As a tip to anyone else using OpenOCD for the first time, beware that the last official release (v10.0.0) is from 2017 (!). Simply installing the latest HEAD version solved all the issues I had initially run into and exposed all the commands I was expecting to have available.

[kelchm]

I was also able to grab a firmware update archive by using a MITM HTTPS proxy while checking for updates in the Qingping+ App. The request to check for firmware updates appears to have multiple types of authentication, the OTA update itself appears to be freely available for download (more details below).

_update_param__1_1_2_0036_1.zip (Backup) _update_param__1_1_2_0036_1.zip (Direct Download)

checkUpdate Request Example (click to expand)

```shell curl -H 'Host: qingplus.cleargrass.com' \ -H 'app-id: com.cleargrass.app.Air' \ -H 'app-tvoc-unit: ppm' \ -H 'app-timezone: America/New_York' \ -H 'user-agent: QingpingPlus/202101192257 CFNetwork/1220.1 Darwin/20.3.0' \ -H 'app-lang: en' \ -H 'timezone-offset: -50' \ -H 'app-timestamp: 1613277163' \ -H 'app-temp-unit: °F' \ -H 'authorization: Bearer XXXXXXXXXXXXXXXXXXXX' \ -H 'accept-language: en-us' \ -H 'app-sign: XXXXXXXXXXXXXXXXXXXX' \ -H 'phone-id: XXXXXXXXXXXXXXXXXXXX' \ -H 'app-reading-standard: cn' \ -H 'accept: */*' \ -H 'app-version: 2.2.8' \ -H 'app-build: 202101192257' \ -H 'app-platform: ios' \ 'https://qingplus.cleargrass.com/firmware/checkUpdate?mac=XXXXXXXXXXXX&model=Goose-Mijia&type=Goose-Mijia&version=1.1.2_0020&version_type=release' ```

checkUpdate Response Example (click to expand)

```json { "data": { "id": 151, "type": 0, "upgrade_sign": 1, "version": "1.1.2_0036", "file_md5": "3aaf5dd1e14f7bb46a47b83d07d213ba", "app_url": "https://qingfs.oss-cn-beijing.aliyuncs.com/firmwares/202008/_update_param__1_1_2_0036_1.zip", "desc": "\u63d0\u5347\u4e86\u8bbe\u5907\u7684\u7a33\u5b9a\u6027\u3002" }, "code": 0 } ```

Archive Contents

• Goose_MiJia.bin
• Goose_MiJia.dat
• manifest.json

At a glance, this structure does seem to match what would be expected for an OTA update archive generated with nrfutil.

---

EDIT: As a quick test, I tried uploading this OTA update via nRF Connect, but it fails with the following error:

DFU failed with error: When writing 'ENTER_BOOTLOADER' command to Buttonless Characteristic of DFU Target: Could not write ENTER_BOOTLOADER command: Write operation failed: BLE_GATT_STATUS_ATTERR_CPS_CCCD_CONFIG_ERROR (0x01FD).

The Nordic S132 v3.0.0 documentation helps explain the meaning of this error a bit further:

ATT Common Profile and Service Error: Client Characteristic Configuration Descriptor improperly configured.

[MacSass]

Great to see you make some progress here - unfortunately I can´t be of much help, as my know-how in that area is not up to par! Looking forward what will be possible ...

[atc1441]

You will most likely need to do the handshake as in the Telink thermometers first to be able to upload OTA at least there it is that way.

Need to get my hands on one CGG1 as this gets intresting and nRF52832 is just the favorite SOC

[fanoush]

The firmware is signed / is using secure DFU so getting OTA working is probably not that useful, only taking apart and reflashing via SWD is the way.

Need to get my hands on one CGG1 as this gets intresting and nRF52832 is just the favorite SOC

BTW any cheap sources of this device? See it for ~$15 here so not exactly cheap when compared to $4 Telink one.

[kelchm]

The firmware is signed / is using secure DFU so getting OTA working is probably not that useful, only taking apart and reflashing via SWD is the way.

I agree that is the case, but I still want to prove it out definitively myself. Since this is the first time working on anything like this, I'm largely treating this as an educational process and trying to take my time and learn as much as possible along the way.

BTW any cheap sources of this device? See it for ~$15 here so not exactly cheap when compared to $4 Telink one.

I'm not able to view the AliExpress link (I guess it's geoblocked), but unfortunately that's about the going rate for the CGG1. I paid ~$22 including shipping for mine from Amazon in the US. They definitely are a tier above the alternatives in build quality and visual appeal though.

[MacSass]

Unfortunately I´m not aware of any cheaper source - I bought mine at aliexpress for this price. From my point of view the much bigger and clearer e-paper display is well worth the price ... if you care about reading and not getting the value via BT only ...

[fanoush]

Since this is the first time working on anything like this, I'm largely treating this as an educational process and trying to take my time and learn as much as possible along the way.

Sure. In theory they could still have signature check disabled in bootloader but it is quite unlikely. The package can be examined with nrfutil tool by Nordic (so it is softdevice S132 3.0.0 = SDK12)

$ nrfutil pkg display cgg1_update_param__1_1_2_0036_1.zip

DFU Package: <cgg1_update_param__1_1_2_0036_1.zip>:
|
|- Image count: 1
|
|- Image #0:
   |- Type: application
   |- Image file: Goose_MiJia.bin
   |- Init packet file: Goose_MiJia.dat
      |
      |- op_code: INIT
      |- signature_type: ECDSA_P256_SHA256
      |- signature (little-endian): daef8764e2d5341df4ad2a5c2a83546457bc7da4dd8314f9b37f6315396d798863da2f55a288f34706fe914efe48c17b25539af0ce87a674d9b31ccab1f7190d
      |
      |- fw_version: 0x000000FF (255)
      |- hw_version 0x00000034 (52)
      |- sd_req: 0x8C
      |- type: APPLICATION

They definitely are a tier above the alternatives in build quality and visual appeal though.

Thanks, just checking what is good price. e-ink probably looks much better so may be worth it indeed. The telink one is indeed small and hard to read. But I don't mind as I have one outside hidden from the rain in a box and another one under the bed in cold corner and one is similar damp corner in a wardrobe :-)

[pvvx]

You will most likely need to do the handshake as in the Telink thermometers first to be able to upload OTA at least there it is that way.

Need to get my hands on one CGG1 as this gets intresting and nRF52832 is just the favorite SOC

Is there a Nordic OTA ready for Chrome (javascript)? CGG1 use Nordic BLE_DFU_SERVICE_UUID 0xFE59 - UUID of the DFU Service.

[atc1441]

Nordic legacy DFU is on the WebBluetooth Blocklist so can not be accessed, only the secure Nordic DFU can be accessed, that is why i never build a web flasher for nordic DFU. Just as info

https://github.com/WebBluetoothCG/registries/blob/master/gatt_blocklist.txt

Hope it helps

[fanoush]

Is there a Nordic OTA ready for Chrome (javascript)?

There is. Some version is part of Espruino Web IDE https://github.com/espruino/EspruinoWebIDE/blob/master/js/libs/secure-dfu.js and it is based on https://thegecko.github.io/web-bluetooth-dfu/examples/web.html

BTW legacy DFU (using different service IDs) is blocked by web bluetooth https://github.com/WebBluetoothCG/registries/blob/master/gatt_blocklist.txt#L19 , the 'secure' one is not (so far).

[pvvx]

I paid ~$22 including shipping for mine from Amazon in the US.

I bought an old version of CGG1 (with the NRF chip) at a local store with delivery on the same day for $14.5. A new version with a Telink chip has a cost of 2 times less. There are no visual differences. Only boxes are different. For energy consumption, they are similar. But SDK NFR does not know how to sleep - constantly wakes up for the work of the timer. https://pvvx.github.io/CGG1_old

[pvvx]

Nordic legacy DFU is on the WebBluetooth Blocklist so can not be accessed, only the secure Nordic DFU can be accessed, that is why i never build a web flasher for nordic DFU. Just as info

Service UUID: 0000fe59-0000-1000-8000-00805f9b34fb -> https://pvvx.github.io/CGG1_old/uuid.txt Nordic BLE_DFU_SERVICE_UUID 0xFE59 - UUID of the DFU Service.

Alternate OTA for all mijia:

const u16 mi_primary_service_uuid = 0xfe95;
#define BLE_UUID_MI_OTA_CTRL    0x0017                    /**< The UUID of the OTA Control Point Characteristic. */
#define BLE_UUID_MI_OTA_DATA    0x0018                    /**< The UUID of the OTA Data Characteristic. */

[atc1441]

The UUID 8ec90003-f315-4f60-9fb8-838830daea50 Is used to get the device into the real nordic bootloader. When 0x01 written to it the device will reboot into nordic bootloader on next reboot which is either legacy or secure

[pvvx]

The UUID 8ec90003-f315-4f60-9fb8-838830daea50 Is used to get the device into the real nordic bootloader. When 0x01 written to it the device will reboot into nordic bootloader on next reboot which is either legacy or secure

---

---

Now we need a test program with BLE access to all Flash and without erasing the old OTA. Read the entire flash and the previous version, and if mijia, then the keys.

[atc1441]

The DFU is a secure one, so there is currently no way of flashing a new firmware to it without the Private key to sign it.

the private key is not in the OTA Bootloader or firmware sadly

[pvvx]

the private key is not in the OTA Bootloader or firmware sadly

The software from the manufacturer cannot change the version? 8-(

The public key is in the firmware. Data blocks for private key recovery are given in OTA. Keys don't change on the go. You can look for collisions for a week - no one is in a hurry :)

[fanoush]

You can look for collisions for a week - no one is in a hurry :)

https://crypto.stackexchange.com/questions/47809/why-havent-any-sha-256-collisions-been-found-yet

[pvvx]

https://crypto.stackexchange.com/questions/47809/why-havent-any-sha-256-collisions-been-found-yet

Example from links: https://eprint.iacr.org/2008/270.pdf And this is 2008 and officially in publication ... :) :P

PS: 2005 - my x65PapuaSoft/JokerA70 for Siemens phone MD5 - all PC 8 seconds :)

[fanoush]

yeah, I've seen it but you need to find collision to existing data, not to generate new pair, there is also the length extension attack, but here you have signed dat file with length and sha256 hash of the binary, so you need your new binary with same length and same hash

[pvvx]

yeah, I've seen it but you need to find collision to existing data, not to generate new pair, there is also the length extension attack, but here you have signed dat file with length and sha256 hash of the binary, so you need your new binary with same length and same hash

Do you think the key certificate itself is filled with randoms? :) And where have mathematicians been since 2008? Everyone was put in jail? :) Something short keys on the Web have been banned ...

---

I don't like ARM. It's boring - there is all the documentation for it. And the CGG1 of this version is on nRF... :(

[fanoush]

Data blocks for private key recovery are given in OTA.

only the dat file/init packet is signed, the firmware binary is not, binary is only hashed and it's sha256 hash (and length) is in init packet/dat file

Do you think the key certificate itself is filled with randoms?

not sure what you mean but you can generate new private key via nrfutil keys generate key.pem and then show matching public key via nrfutil keys display --key pk key.pem --format code. if you think deriving private key from ECDSA_P256_SHA256 public key is easier then go for it, other option is to keep dat file and signature as is and find new firmware binary having same length and same sha256 hash. I guess both problems are currently considered to take a bit more than a week :-)

[pvvx]

The hash is definitely faster to calculate up. Moreover, there are probably source codes for the ota-bootloader...

[fanoush]

there are probably source codes for the ota-bootloader

sure, just get any sdk>=12 from https://developer.nordicsemi.com/nRF5_SDK/ and see components/libraries/bootloader/ and examples/dfu/bootloader_secure inside, the crypto libraries used is in external/micro-ecc/micro-ecc

You can of course build new bootloader and replace it in the device via SWD or replace just the public key in it with your own or disable the signature check, but that is not the point here I guess?

[pvvx]

Before poking around with OTA Nordic keys, you need to find out - They say that the old CGG1 is being flashed to a version that supports Mi-Home. It may contain mijia OTA. And this is another option.

---

2. Secure Boot Validation As mentioned in the above section, there is a boot validation performed at the booting phase of the bootloader. In SDK v15.2* and earlier, it's simply a CRC check of the application image.

• nRF5 SDK v15.2.0 Release Date: Week 37, 2018

My CGG1 product date 2018.11
How can I find out the SDK version without opening the device?

[pvvx]

Disassembled the device: https://pvvx.github.io/CGG1_old Chips Marking: N52810QFAAB0, MD25D80SIG, SHT30 Original Full-Flash (SEGGER JFlash)

You can of course build new bootloader and replace it in the device via SWD or replace just the public key in it with your own or disable the signature check, but that is not the point here I guess?

Looks like this version of CGG1 are not required keys. Interest is gone... Next, you need to create the firmware in the SDK. We'll have to look for another version of CGG1 - there are already 4 of them. 3 types are disassembled and there is a photo of the boards in github. CGG1-H remained unknown.

PS: Next: https://pvvx.github.io/LYWSD02

[atc1441]

Thumbs down for 52810 ... bad chip :D To small flash and ram

+1 for LYWSD02 Finally a Dialog custom firmware would be good

[fanoush]

Before poking around with OTA Nordic keys, you need to find out - They say that the old CGG1 is being flashed to a version that supports Mi-Home. It may contain mijia OTA. And this is another option.

2. Secure Boot Validation As mentioned in the above section, there is a boot validation performed at the booting phase of the bootloader. In SDK v15.2* and earlier, it's simply a CRC check of the application image.

• nRF5 SDK v15.2.0 Release Date: Week 37, 2018

My CGG1 product date 2018.11 How can I find out the SDK version without opening the device?

If you have dfu update package, SoftDevice version is in sd_req field see https://github.com/kelchm/cgg1-thermometer-firmware/issues/1#issuecomment-783202718 If you have full flash backup softdevice version is 16bit value at location 0x300c. If you only have application binary it can be guessed from location of interrupt vectors and sometimes from softdevice and sdk debug symbols/method names if they are left in the code.

If the only way is to update via swd you can also pick any sdk you like and replace everything.

[pvvx]

If you have dfu update package, SoftDevice version is in sd_req field see #1 (comment) If you have full flash backup softdevice version is 16bit value at location 0x300c. If you only have application binary it can be guessed from location of interrupt vectors and sometimes from softdevice and sdk debug symbols/method names if they are left in the code.

If the only way is to update via swd you can also pick any sdk you like and replace everything.

This means that it is impossible for the user to determine the version of the SDK without disassembling the device with a hot air gun and then throw it away?

[atc1441]

If a stock firmware is available yes

[pvvx]

It follows from this that if the device has nRF - no alternative firmware.

[atc1441]

Yes, unless there is any other exploit in the firmware or swd pins available

[pvvx]

Thumbs down for 52810 ... bad chip :D To small flash and ram

Installed additional Flash 1 MB (MD25D80SIG)

[atc1441]

@fanoush and i are quite active in the nRF52 smartwatch hacking "scene" just as info

The 1MB aditional flash make it possible to use but its a hassle and hard to use default SoftDevice then.

There where also mi thermometers with nRF52832 available if i remember correctly, but as it looks like the switch to tlsr on many of them i would care about nRF anymore

[pvvx]

There where also mi thermometers with nRF52832 available if i remember correctly, but as it looks like the switch to tlsr on many of them i would care about nRF anymore

How long does Nordic's minimum BLE stack code size? Is it worth fighting these Scandinavian expensive monsters?

The Chinese have a lot more BLE chips with government support, that is, cheaper and with normal performance. For example PHY62x2.

RTL8762C_mijia_ble_standard113-HT_Demo - All listings and objs for assembly are specially left in it, for those who are not given the mijia libraries.

[pvvx]

If you have full flash backup softdevice version is 16bit value at location 0x300c. If you only have application binary it can be guessed from location of interrupt vectors and sometimes from softdevice and sdk debug symbols/method names if they are left in the code.

fccid 2AQ3F-CGG1 2018-09-04 (nRF52810) Original Full-Flash (SEGGER JFlash)

No fccid! CGG1 (nRF52832) cgg1-stock-1.1.2_0020.hex.zip

https://github.com/kelchm/cgg1-thermometer-firmware/wiki/Stock-Firmware -> cgg1-bank0-stock-1.1.2_0020.bin

[fanoush]

list of softdevice ids is in nrfutil, --help option fo package creation, also most of them are here https://devzone.nordicsemi.com/f/nordic-q-a/1171/how-do-i-access-softdevice-version-string 8c is s132 3.0.0 so sdk12, a6 is s112 5.1

[fanoush]

Is it worth fighting these Scandinavian expensive monsters?

nrf52 chips are nice if you want good software support in projects like micropython, espruino or arduino, also there are two opensource certified bluetooth stacks one in Zephyr OS and one i Apache Newt - NimBLE. If you are ok with chinese vendor's sdk and can just modify some example then you won't appreciate that. best chips worth of hacking are 52832,52840,52833 - lot of ram and flash. those cutdown cheap ones like 52810/11 are not best choices but still may be good for small C project - like thermometer :-)

[pvvx]

list of softdevice ids is in nrfutil, --help option fo package creation, also most of them are here https://devzone.nordicsemi.com/f/nordic-q-a/1171/how-do-i-access-softdevice-version-string 8c is s132 3.0.0 so sdk12, a6 is s112 5.1

Does this mean there are no hashes in the OTA? Can't try OTA until I read the external Flash. OTA will probably ruin everything there...

nrf52 chips are nice if you want good software support in projects like micropython, espruino or arduino

Everything described does not make sense in the reality of working devices. You can screw everything up, but this is not a working option - just a game.

I do not need Arduino. Arduino for children, for the game only. :) Why does a sensor need more than a kilobyte of RAM? 8-) Or why the RTOS sensor and the C++ ? Small SoCs have no MMU and the heap is defragmented -> exception. Those. unstable device = Ardunio.

52810 low power (vs 52832).

[pvvx]

Is it worth fighting these Scandinavian expensive monsters?

nrf52 chips are nice ...

Examples from Nordic for this chip :) monsters! :)

---

This is everything that is writte in the external Flash MD25D80SIG:

[kelchm]

First of all -- it's super exciting to see everyone chiming in to discuss the nRF based CGG1.

I've been very torn on what I whether I wanted to pursue this project any further after @pvvx reported receiving a Telink based CGG1 (and since receiving one myself). I'm not an embedded developer, and while I was looking forward to using this project to get myself a bit outside of my comfort zone, it's also somewhat demotivating to know that the remaining supply of nRF based CGG1s is likely limited and that there's clearly a cheaper/easier path to the same end goal via the Telink based hardware.

Finding a way to exploit Nordic's secure OTA DFU would definitely be a bit of a game changer in making this project more viable -- there's really no getting around how much of a pain it is to disassemble the CGG1. 😅

I wouldn't be at all surprised if someone was able to exploit Nordic's secure OTA DFU implementation -- just look at the APPROTECT bypass as an example of how seemingly secure systems can be trivially bypassed. This is admittedly something that's well outside my own existing skillset, but I'd love to be contribute if anyone wants to really dig into investigating this further.

[fanoush]

Does this mean there are no hashes in the OTA?

SDK12 and up uses secure OTA so both are new enough to have this unfortunately. With smartwatches based on nrf52 it is similar, only very few models still sold are build with SDK11, with the rest we focus on those with custom OTA (DaFit) or those with swd on charger pins. Softdevice S132 3.0.0 probably has some exploit, posible buffer overflow is mentioned in 3.1.0 release notes.

[pvvx]

SEGGER Embedded Studio for ARM Release 5.42 (Windows x64) and Keil uVision V5 work badly with Nordic SDK with SEGGER Jtag (SWD). Settings and other glitches are incorrectly spelled out...

When writing a new firmware, SES writes that everything is fine. Check 'Verify' - ok. But the firmware is wrong - no chunks. When dancing with a tambourine around Jtag from SEGGER, normal firmware is successful, but sometimes. Jtag from SEGGER I have several different ones. In utilities from SEGGER - everything works well with nRF52810, including JFlash. From IDE with Nordic SDK - no.

S312 for 52810 and S332 for 52832 require registration ...

In this regard, the creation of an alternative firmware for the NRF has been postponed indefinitely. There is no time to dig in the Nordic dump yet...

[fanoush]

why would you use S312? That's one with additional ANT protocol (which needs license). I use gcc and cheap STLINK clone or CMSIS-DAP with openocd and gdb so cannot comment on SEGGER (And IDEs are for kids ;-))

[pvvx]

why would you use S312? That's one with additional ANT protocol (which needs license).

It is clearly smaller, which Nordic throws out for its users.

I use gcc and cheap STLINK clone or CMSIS-DAP with openocd and gdb so cannot comment on SEGGER (And IDEs are for kids ;-))

Yes, yes, I have weeks of my life to write scripts for boiled porridge for decades at Nordic. They themselves have not been able to do this in decades. So you have to do everything yourself? You said that everything is easy and simple on nRF and a crowd of fans with a streamlined software... I didn’t notice - we need to redo everything or forget about the Nordic.

Alternative programming of nRF chips is only for the dedicated and not suitable for DIY.

---

I tested a couple of examples - everything is bad with the nRF52810. The amount of Flash for the program is small and you can only repeat what has already been done by ‘Cleargrass’. The original advertising packages are not encrypted, data is transmitted constantly. It has no meaning in alternative firmware, except for the game.

[fanoush]

the softdevice numbering is a bit complicated but mostly makes sense Sxyz - x=1 BLE, x=2 ANT x=3 both, y=1 peripheral, 2 central 3 both, last number is mostly related to supported chip 0-nrf51 2-nrf52 or some minor feature difference (e.g. S113 has DLE extensions, S112 not). Also for nrf52840 it ends with 40

So for 52810 you could use S132 or S113 or S112 , also visible on chip page https://www.nordicsemi.com/Products/Low-power-short-range-wireless/nRF52810 - compatible soft devices on the bottom.

only for the dedicated and not suitable for DIY

It takes a bit of time to understand, like anything else. Documentation is pretty good and extensive (unlike Chinese stuff) - https://infocenter.nordicsemi.com/topic/struct_nrf52/struct/nrf52.html Definitely suitable for hobbyists e.g. adafruint has tons of nrf52 boards, aliexpress is full of them, microbit is based on it, as mentioned there are two opensource certified BLE stacks in addition to binary softdevices - there wouldn't be so much stuff for it if it was 'not suitable'.

[pvvx]

Adafruint has nrf52 boards ... :) They were thrown into the DIY market as a product not in demand from other manufacturers. Better to spend time and add the option Zigbee to thermometers with TLSR chips . I have already tried it - it works and registred in Mi-Home (+ Gateway 3).

---

It takes a bit of time to understand, like anything else. Documentation is pretty good and extensive (unlike Chinese stuff)

There is more extensive documentation on Linux, but not everyone creates drivers for the kernel :) The ESP8266 did not have and does not have any documentation ... There were pathetic scraps in Chinese. Riddles are the backbone of popular DIY folk movements.

PS: Being a fan of a piece of iron is not good.

[fanoush]

Better to spend time and add the option Zigbee to thermometers with TLSR chips

Indeed :-) What you did with Telink chips so far is great so maybe it is better for everyone if you just continue doing what you like instead of fighting with nrf52 :-)

[pvvx]

I have not seen any differences in different chips for a long time. It took 15 minutes to run my code to measure the power consumption on the nRF52810 = soldering the connector for the SWD + Downloading the SDK + finalizing the first example that came across. But further - the continuous struggle with glitches and perversions of the SDK from Nordic with unstable recording of programs ... Ie. you have to redo everything in your own way. And the reason is that the community of nRF lovers has not yet given birth to anything worthwhile. nrf52840 in Arduino consumes half of CR2032 at startup - this is a great achievement for nRF fans, field of 4 years of nrF52 release series :)

@fanoush - You write that a lot of fanats and everything in nRF is simple and even without IDE - then throw in the source of a power-optimized example of working with a temperature and humidity sensor using i2c (typical SHT30) and with DFU / OTA for nRF52810 and nRF52832. And this would help the author of this repository.