p8b-infinitime icon indicating copy to clipboard operation
p8b-infinitime copied to clipboard

Stuck installing infinitime on my p8b running Wasp-OS Bootloader

Open jds11111 opened this issue 6 months ago • 10 comments

Am kind of lost at this point, so anyone pointing me at some good info would be appreciated.

jds11111 avatar Jul 13 '25 17:07 jds11111

Hello, I just reprogrammed one Colmi P8b device that was running MOY-TON5-2.0.4 official (but the same process worked in the past also for a device that was running MOY-TON5-1.8.4)

I'm writing down the detailed steps below, hoping that this will help you, @jds11111 . From what you wrote, you can directly start at step 4 below...

I cloned this repo and also fetched the precompiled binaries for release 1.11.0.0. In my case, it was moy_ton5.zip.

The whole upgrade process is detailed in https://github.com/StarGate01/p8b-infinitime?tab=readme-ov-file#ota-stock-upgrade-path

To have a demo of the first 3 steps, you can actually have a look at the demo video at https://www.youtube.com/watch?v=gUVEz-pxhgg

To get all DaFlasherFiles, I moved to the topdir of this github repo, and issued:

git submodule update --init DaFlasherFiles/
  • Step 1 is identical to the above demo video between timestamp 02:06 and 04:24, then Select File using the very same file (DaFlasherFiles/DaFitBootloader23Hacked.bin), that you will have transferred beforehand to the Android smartphone or tablet running the DaFitFlasher app.

At the end of this step, the watch reboots with 3 squares displayed on the screen (red, green and blue).

  • Step 2 is identical to the above demo video between timestamp 04:24 and 06:18, press DFU Update then Select DFU File using the very same file (DaFlasherFiles/FitBootloaderDFU2.0.1.zip, that you will have transferred beforehand to the Android smartphone or tablet running the DaFitFlasher app. Make sure Toggle Bluetooth is already checked, which means the device is properly recognized over bluetooth. If this is not the case, please restart the DaFlasher app and rescan once more. I had to also check Use Nordic Bootloader here (and also stop/Start bluetooth and restart the DaFitFlasher app even if 'm not sure this is really necessary). At the end of this step, the watch reboots with 1 red square displayed on the screen (like on the demo)

  • Step 3 follows the same procedure as the above demo video but uses a different file. The video demonstrates the process between timestamps 06:18 and 8:37, press DFU Update then Select DFU File, but for my p8b, I used file bootloader-daflasher.zip as indicated in the step 3 details of this repo's README (rather than the P8TestMenu.ino.zip displayed in the video. Of course, once more, you will have to transfer bootloader-daflasher.zip beforehand to the Android smartphone or tablet running the DaFitFlasher app. I had to restart the DaFitFlasher app to detect the watch via Bluetooth before starting step 3. Make sure Toggle Bluetooth is already checked, which means the device is properly recognized over bluetooth. If this is not the case, please restart the DaFlasher app and rescan once more. File bootloader-daflasher.zip was not taken from the path in the README, but rather from the extracted pre-built archive for the zip release corresponding my watch model. I had a few occurrences of "ERROR invalid crc error" messages, but the upgrade went through after a few retries. At the end of this step, the watch reboots and displays a white wasp on the screen.

[!Warning]
@jds11111, from the title of your ticket, it looks like you are stuck here, having successfully performed step 3, but unable to complete step 4.

  • For me, running step 4 required some tricks compared to the provided files. First, I moved to the topdir of this github repo and issued:
git submodule update --init --recursive wasp-os/

To run the script, I had to pip install pexpect (in a virtual env in my case) Here, actually, I manually executed the last line of the script scripts/load_wasp_reloader.sh in my terminal, rather than executing the script itself. The value of the variable ADDR was wrong, I used the bluetooth address displayed on my watch prior to the upgrade. In my case, for both the models I upgraded, that address started either with CC:A3:B0 or with EF:1D:FE. If you didn't write this down before, you can get the MAC address by running a new scan using DaFlasher The whole line that replaced step 4 was:

tools/ota-dfu/dfu.py -v -z ../moy_ton5/reloader-factory.zip -a CC:A3:B0:xx:yy:zz --legacy

Probably due to an incompatibility between the python scripts and my version of gatttool (part of bluez package, which was in v5.72 on my machine), I had to adapt the script in wasp-os/tools/ota-dfu/nrf_ble_dfu_controller.py. I performed the following change. I replaced (around line 231):

res = self.ble_conn.expect('Characteristic value was written successfully.*', timeout=10)

with

res = self.ble_conn.expect('Characteristic value was written successfully[^\r]*', timeout=10)

[!Tip]
The regular expression catches the following line (with the .* wildcard) and that next line is then not seen during the rest of the process, leading to a failure.

Of course, this needs to be run on a machine with bluetooth enabled and working, so previous tests may be required. No need to press Start on the waspos display, as soon as the above python script is started, the bluetooth logo on it will turn blue and progress report will be displayed on the python script's console. This step takes a while. When transfer is finished, the watch's display shows a small blue pine, that slowly fills with white. The display then blanks. The watch then displays a big white pine, that progressively turns green. Infinitime logo is displayed with progress bar at the bottom, that turns green. This completes steps 5, 6 and 7 that all complete automatically without user interaction. It will not properly boot Infinitime yet because the Infinitime app is not loaded yet. We will fix this in the next step (8)

  • Step 8 In an infinite loop, a big white pinecone is displayed, then Infinitime tries to boot. Like in the README instructions, while the white pinecone is displayed, you should keep the button pressed until the pinecone turns blue, a keep pressing until it turns red. When this is done (red pinecone), the watch will reboot in recovery mode. You will see again the pinecome fill in with green. This is the recovery booting, don't interrupt anything this time (no button press, no red pinecone). Inifinitime's logo will be displayed again, but without progress bar., indicating that we are now in recovery mode, ready to load the full pinetime app.

  • Step 9 Once more, at step 9, I executed the following command manually (rather than the script scripts/load_infinitime.sh) with my own pinetime app version and bluetooth address (like at step 4):

tools/ota-dfu/dfu.py -v -z ../moy_ton5/pinetime-mcuboot-app-dfu-1.11.0.zip -a CC:A3:B0:xx:yy:zz --legacy

The infinitime logo will turn green on the watch as soon as the transfer begins, and progress will be displayed on the python's script console.

If you get an exception about a UUID not found, you may have the same issue as me: when the script runs gatttool's command characteristics, the response may take too much time. I just increased the timeout of the expect line. Initially, it was set to 2, I increased it to 10 in my case. In file nrf_ble_dfu_controller.py, within function _get_handles(), change:

         self.ble_conn.sendline('characteristics')
 
         try:
             self.ble_conn.expect([uuid], timeout=2)
             handles = re.findall(b'.*handle: (0x....),.*char value handle: (0x....)', self.ble_conn.before)

to

         self.ble_conn.sendline('characteristics')
 
         try:

             self.ble_conn.expect([uuid], timeout=5)
             handles = re.findall(b'.*handle: (0x....),.*char value handle: (0x....)', self.ble_conn.before)

I also enabled verbose mode by using the following line at the top of ble_legacy_dfu_controller.py:

verbose = True

This may have slowed things down and may give more chances for the transfer to reach 100%. I had to do it 3 times though... but it eventually succeeded...

It will take some time and must reach 100% without any exception on the python console in order to succeed. If this is not the case, just reboot the watch (long button press), and immediately interrupt once more with a red pinecone to boot again to recovery (then restart over from step 8, executing the dfu.py command).

I hope this can help you (and others)

lains avatar Aug 17 '25 21:08 lains

Excellent writeup, thank you for your contribution!

StarGate01 avatar Aug 25 '25 11:08 StarGate01

You're welcome. Thanks for the work you've done to port infinitime on this device, I really appreciated it. And because I could manage to reprogram two devices, I thought I would share my experience (and workarounds).

lains avatar Aug 26 '25 08:08 lains

@StarGate01, is there any chance to see a new p8b-compatible release of infinitime above the current 1.11.0.0? I saw that you have been working on integrating support for p8b upstream but it does not seem finished yet...

lains avatar Aug 26 '25 08:08 lains

Well there is no technical reason why we could not port a newer version to the P8. However, upstream has deviated quite a bit in the meantime, so rebasing my patches has become more and more work - and my personal availability in terms of time has also changed. I am no longer able to invest so much time in this endeavor, but I would love to see the project to continue. I don't know how likely it is to integrate the patches into upstream, since NRF52 watches are getting rarer these days though.

StarGate01 avatar Aug 26 '25 11:08 StarGate01

Thank you @lains for the write-up! I am now stuck trying to clone wasp-os. It asks me for a password at

Cloning into '.../DaFlasher/p8b-infinitime/wasp-os/wasp/modules/bma42x-upy/BMA423-Sensor-API'...
Username for 'https://github.com': error: unable to read askpass response from '/usr/bin/ksshaskpass'

jdschi avatar Aug 29 '25 15:08 jdschi

@jdschi, I guess the message above was the result of you running:

git submodule update --init --recursive wasp-os/

As an alternative, you can also manually clone the data, and you probably don't need the whole wasp-os/ directory (~6GB), but just the ota-dfu part (~450KB), so you probably can also get away with the following command:

mkdir -p wasp-os/tools/ && cd wasp-os/tools/ && git clone --recursive https://github.com/daniel-thompson/ota-dfu-python ota-dfu && cd ota-dfu && git checkout 3d6fd30d33c2b20bc86ff6b9269fddf4a1d4c7c6

lains avatar Aug 29 '25 16:08 lains

@jdschi, I guess the message above was the result of you running:

git submodule update --init --recursive wasp-os/

As an alternative, you can also manually clone the data, and you probably don't need the whole wasp-os/ directory (~6GB), but just the ota-dfu part (~450KB), so you probably can also get away with the following command:

mkdir -p wasp-os/tools/ && cd wasp-os/tools/ && git clone --recursive https://github.com/daniel-thompson/ota-dfu-python ota-dfu && cd ota-dfu && git checkout 3d6fd30d33c2b20bc86ff6b9269fddf4a1d4c7c6

EDIT: Maybe never mind. Repeated attempts started getting it uploading.

I cloned just the required bits. Tried running dfu.py the way that you did. It runs for about 20 seconds but throws an error:

Sending file reloader-factory.bin to E2:DB:C6:....
Binary imge size: 221528
Binary CRC32: 3022807715
Connecting to E2:DB:C6:...
Waiting for Image Size notification
Waiting for INIT DFU notification
Exception at line 166: a bytes-like object is required, not 'str'
DFU Server done

Should I be concerned that the MAC address doesn't match your pattern?

jdschi avatar Aug 29 '25 17:08 jdschi

OK, after a couple retries, Step 4 worked. In step 9 struggled, so I increased the timeout, but that might have been unnecessary. After booting up in recovery mode, the MAC address changed slightly. The last digit decremented by one, and it took me a few tries before I noticed it. Who knows why? But now it uploaded fine, and is now paired with GadgetBridge.

THANK YOU for sharing your work. Great write up.

jdschi avatar Aug 29 '25 18:08 jdschi

Hi. Glad to read that you could finish programming your p8b watch. There are indeed two MAC addresses: one in normal mode, one in DFU mode. The difference between these two addresses is +1/-1, hence the change in MAC address you mention above. You can run a new scan using DaFlasher to know which one the device is currently broadcasting and so which one to provide on the command-line (depending on the step).

lains avatar Sep 02 '25 06:09 lains