P8 support

[nextfullstorm]

Hi,
can anyone tell me how to build Infinetime for Colmi P8? It's wide-known clone of Pinetime (or Pinetime clone of P8? I'm not sure). This awesome project proves that there is little to no difference in hardware and pinout differs. I don't have enough skill to resolve it myself. After blind dfu upgrade from stock fw to latest Infinitime release my device was bricked and I have to restore it via SWD programmer.

[JF002]

Hi!
I'm not working on a P8 port for now, because I do not have one and I doubt I would have the time to maintain both of them.
You're right, there are very few differences between the PineTime and the P8, so the port should not be too complicated. I'm open to pull requests if someone wants to implement the support for the P8 :)

Please note that the DFU upgrade from ATCWatch and InfiniTime are not compatible. ATCWatch and InfiniTime do not use the same bootloader and memory map, which means that you can DFU from ATCWatch to InfiniTime or from InfiniTime to ATCWatch.
There is a project to build a tool that would allow that but I don't think it's ready to be used for now.

[maidenone]

i have worked with DFU and NRF52, it should be possible to create a new DFU package that contains the correct bootloader.

[hrmckay]

If you look at issue # 69 for the wasp-os support for the Pinetime at https://github.com/daniel-thompson/wasp-os/issues you will see what had to be changed to get things working for that operating system.

Hugh

[nextfullstorm]

Tnx guys. As I understand, main problem here is memory map difference. And THAN maybe pinout/accelerometer difference. I will look into this and write back if I have meaningful result.

[maidenone]

where can i buy a p8?

…

On Tue, 15 Sep 2020, 08:55 nextfullstorm, ***@***.***> wrote: Tnx guys. As I understand, main problem here is memory map difference. And THAN maybe pinout/accelerometer difference. I will look into this and write back if I have meaningful result. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#62 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJCSUG7KNXQVAYKW5IKWILSF4FVPANCNFSM4RLHTKJQ> .

[nextfullstorm]

where can i buy a p8?

On aliexpress for sure. I got mine there. IDK if I can post direct links.

[maidenone]

well i ordered 2, will se when i get them.
do not know when i will get the time, but i intend to look into it.

[JF002]

i have worked with DFU and NRF52, it should be possible to create a new DFU package that contains the correct bootloader.

@maidenone The tool I was talking about is wasp-reloader. You might want to have a look at it before you start something from scratch :)
And thanks in advance for your futur PR for the support of the P8 in InfiniTime :)

Tnx guys. As I understand, main problem here is memory map difference. And THAN maybe pinout/accelerometer difference. I will look into this and write back if I have meaningful result.

@nextfullstorm It's not only a memory map issue: the bootloader philosophy is completely different. ATCWatch is based on the NRF softdevice (BLE stack) and NRF bootloader. The BLE stack is shared accross the bootloader and the application (atcwatch). It provides many advantages, but it forces in a way all application firmware to use the NRF Softdevice as BLE stack. And the softdevice and the bootloader are both closed-source.

The bootloader implemented by InfiniTime and other compatible firmwares is a much more simple bootloader that does not provide any BLE stack. It allows the developers to choose the BLE stack they want for their project (or no ble at all). It is then possible to implement a fully open-source application: the bootloader is based on MCUBoot and you can use NimBLE as ble stack. They are both open source.

The way the NRFBootloader and softdevice are designed make the cohabition really difficult. The best solution for this issue we've found so far is to implement a "swticher" tool that would use OTA to overwrite the bootloader from MCUboot to NRF and vice-versa. Danielt began the project (wasp-reloader) but I haven't had the time to check it out.

[nextfullstorm]

@JF002 Thanks again. This is very useful info for noobs like me. Maybe you should include it somehow in main README.

[tt1pjm]

I created a fork and have flashed pinetime-app.out to a P8 that seems to be functional. Only a few pins needed to be modified. I've not yet managed to get MCUBoot bootloader working yet for the P8. If anyone makes any progress on that please share.

[endian-albin]

@tt1pjm: PineTime Hypnos has a P8 port with mcuboot enabled, but I don't know if DFU works on it since I don't have access to a P8 device. Please note that the slot1 partition is located on the external SPI flash. I have no idea if that is right or wrong on the P8. If you put slot1 on the the internal flash, then the Hypnos application will run out of space. Anyway, binaries are available in the Github Actions history.

[tt1pjm]

@endian-albin: Good work on building support for P8 in Hypnos! I managed to get MCUboot working on my P8, take a look at my fork of Lup's pinetime-rust-mynewt for details. I don't know if all P8s have the same jedec manufacturer for SPIflash as mine but it was different to Pinetime and needed correcting for MCUBoot to work. Looks as though you've got the same jedec manufacturer for P8 as Pinetime in Hypnos so may need updating if other P8 owners validate they have the same jedec manufacturer that I've identified.

[endian-albin]

The port was contributed by @MirkoCovizzi and as I said, I haven't been able to test it myself. From what you say, it sounds like we need to make modifications, but I'll leave that to someone who can actually try it out. By the way, do you happen to know where one can get a P8 with SWD pin access?

[tt1pjm]

I'll try and test the change and let you know how it goes over at Hypnos. P8s come closed and just need back cover removing with a blade to access the SWD pins. They're quite common and can be found searching for Colmi P8.

[endian-albin]

Thanks @tt1pjm!

[maidenone]

@endian-albin
see my posts here: #53

i will set up integration testing nodes for P8 and Pinetime. they will be available online through a web interface. i can also provide direct ssh access if asked ^_^

[endian-albin]

@maidenone, that sounds awesome. I'm looking forward to try it out when ready.

[JF002]

Thanks for working on a port of InfiniTime on the P8.
To avoid confusion, we'll need to be very clear about the fact that the bootloader and OTA from InfiniTime are not compatible with the original FW running on the P8 and with Wasp-OS. I don't want people to brick their device while trying InfiniTime :)

[jones139]

I have just ordered a second P8 in anticipation of having to open up the first when I brick it 😀.

I'll give it a try tonight.

[maidenone]

Do you have any good linux commandline tools to do make DFU upgrade requests?

I would like to create "fw upgrade" tests and add them to my integration test framework,
see: https://forum.pine64.org/showthread.php?tid=11711

In the past I have used https://github.com/peplin/pygatt to automate testing and do stress testing on custom Bluetooth services I have created.

[Avamander]

Do you have any good linux commandline tools to do make DFU upgrade requests?

@maidenone use adafruit-nrfutil pip package

[maidenone]

looks like the adafruit lib only supports serial dfu, not ble dfu.

this looks right: https://github.com/NordicSemiconductor/pc-nrfutil/blob/master/nordicsemi/dfu/dfu_transport_ble.py

[Avamander]

@maidenone

looks like the adafruit lib only supports serial dfu, not ble dfu.

You are absolutely correct. When I replied to you it was getting pretty late and I thought you just want to make "DFU distribution packets". For which that library works well. I used it to quickly generate the .zip needed for Gadgetbridge or nRF Connect.

[maidenone]

just to clarify my plan:
The test will

1. flash bootloader + firmware/app or only bootloader if supported
2. the test framework will then try to make the bootloader enter dfu mode, either through pi hardware (button press?) or through "buttonless dfu" if available.
3. the test framework will then make a ble dfu upgrade request through RPI BLE (or NRF BLE dongle).
4. the test framework will then wait / reboot the pinetime and verify that the update succeeded (RTT output? debug trace? pin toggle?)

this will make it faster / easier to test / develop solutions for moving from one bootloader to another, verify normal dfu upgrade packages or creating tests that repeatedly can cause some hard to trigger upgrade bugs.

[Avamander]

What you describe sounds very similar with what I thought of doing, but the primary difference with yours being that I don't really wish to write a custom UI/service, the status and everything will hopefully be available as build artifacts or in CI log. I was personally planning on creating a CI pipeline for TeamCity that flashes the firmware, grabs the ARM Semihosting logs, takes a few pics with a webcam and then posts the build status.

[maidenone]

shhh, ARM Semihosting, isnt that a bad word?
I have had BLE timing issues with the softdevice when using semihosting

[Avamander]

shhh, ARM Semihosting, isnt that a bad word?

It works if you don't use it in timing-critical situations, plus it's not proprietary and it's nicely supported by OpenOCD. It's more universal than RTT.

The speed of ARM Semihosting also depends on the programmer's speed, the defaults are often silly. If you use openocd, give it adapter speed 32000 and divide the time it takes to flash by ten.

[maidenone]

if you want to dig deeper see this: https://blog.japaric.io/itm/
summery: "Never, ever use semihosting to log data. Unless you can afford delays in the order of tens of milliseconds in your application."

It was with strong dislike that i went from the light fields of OpenOCD into the dark plains of JlinkRTT, now i am afraid i will never see the light again...

that said, i do a fair bit of time critical things, and being able to dump out a metric crap ton of debug data without missing realtime constraints is a true blessing.

Also, RTT in OpenOCD might happen any year now: http://openocd.zylin.com/#/c/4055/

Back to topic? sorry for derailing this thread.

[maidenone]

What you describe sounds very similar with what I thought of doing, but the primary difference with yours being that I don't really wish to write a custom UI/service.

you might be able to use the commandline interface?

python3 runOnTestNode.py dfuUpgradeTest node1 test.hex

The drawback is that i currently do not have any "job id", only "execution datetime", and if the node is busy and your job is queued, you will have a hard time reading out the test result. unless you want to hang around reading real time debug output during the entire execution.

i might have to update the API for that specific usecase, to be able to provide both bin/hex to be flashed and a dfu package to upgrade to.

[Avamander]

if you want to dig deeper see this: https://blog.japaric.io/itm/
summery: "Never, ever use semihosting to log data. Unless you can afford delays in the order of tens of milliseconds in your application."

I think the author might've made the exact same mistake of not increasing the adapter speed...

[nica-f]

So, as a kind of heads, here am I as a new interested in person in Infinitime on the P8 ;) I have got myself a couple P8b from eBay, turned out to be MOY-TIN5-1.8.2
Flashing over the air using atc1441's bootloader and reloader-factory-P8.zip did not work for, I ended up with a brick. So I opened the bricked watch and took some pictures from the inside, if it helps anyone:
https://www.dpin.de/cloud/index.php/s/cmjZBkNB2XyRXPs
Next I will attach an STLink SWD and go from there... but goal is of course to reflash on of the other P8b via OTA somehow.

[ildar]

On Tue, Oct 19, 2021 at 5:43 PM Nicole Faerber wrote: Flashing over the air using atc1441's bootloader and reloader-factory-P8.zip did not work for, I ended up with a brick.

#62 (comment) says:

…

If you already have the *Wasp bootloader*, you don't need to unseal your gadget, you can install OTA: reloader-factory-P8.zip

[nica-f]

Umm... then I am not sure, all these different how-tos are a bit confusing. What is the WASP bootloader and how would I get it onto the factory P8b? The only bootloader I found so far that can be flashed with daflasher OTA on a factory P8b is the DaFitBootloader23Hacked.bin from https://github.com/atc1441/DaFlasherFiles
This again did not allow to flash the reloader-factory-P8.zip directly, probably because of the reasons mentioned in #62 (comment)

[fanoush]

@nica-f which other howto you followed? I hoped the only wrong one was here in this thread by @ildar and that is already fixed?

MOY-TIN5 is not a bad one nowadays, it still has 32kHz crystal but no longer BMA421, that one was replaced by SC7A20 so no builtin step counter.

WASPOS is micropython based firmware based on softdevice S132 6.x, guide here https://wasp-os.readthedocs.io/en/latest/install.html#daflasher-for-android , for P8 you are looking for bootloader-daflasher.zip suitable for P8. then maybe you could use the file that bricked your device as it is built for 6.x version of S132 softdevice

[DiegoBM]

Hi everyone, is there a safe and well defined process to flash infiniTime from a working P8b with Espruino using OTA? Same as there is for Wasp Bootloader I'd like to give infiniTime a go. And if there is such process, does it allow to go back to Espruino still using OTA for flashing?

Also is there any tutorial or guide anywhere that explains how to open the device and connect to the SWD pins? Ideally visually with either pictures or a video.

Thanks!

Note: I used enaon's guide to install Espruino on my P8 (https://enaon.github.io/eucWatch/tools/hackme/)

[nica-f]

I did cut open one P8b for development and attached the SWD wired to an STLinkV2 which now works fine with OpenOCD. After playing with some other firmware projects I went back to Infinitime and would like to help fixing some P8 issues in it. But I need some form of logging. With another toy project I used the almost infamous ARM semihosting - which works totally fine for me to get at least some idea of what is happening in the code and getting some debug output.

I have successfully rebuild the P8 port of the Pinetime mcuboot (from here https://github.com/kung1388/mcuboot-bootloader-P8) to output via semihosting:

Starting Bootloader...
Displaying boot logo...
Displaying version image...
Waiting 5 seconds for button...
step 1 - 0
step 2 - 0
step 3 - 0
step 4 - 0
step 5 - 0
Waited 5 seconds (0)
MCUBoot processing...
[INF] Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[INF] Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[INF] Boot source: primary slot
[INF] Swap type: none
Bootloader done

In Infinitime though I seem not to be able to find a way to define which debug output to use? Is only RTT supported right now? Or is it possible to enable semihosting output somehow?

[ildar]

I suggest that developing issues better answered at PineTime chats. BTW yours aren't P8-specific.

[fanoush]

BTW Segger RTT is working also in recent openocd with any swd debugger and is lighter than semihosting so maybe having just that is not so bad.

[nica-f]

Oh, that would be really helpful, for P8 development of course.
I have set up the latest OpenOCD (with my STLinkV2), did enable RTT in the src/sdk_config.h (and recompiled) and am now struggling a bit with the RTT, it requires an address, buffer size and ID - which seem to be implicit with JLink but OpenOCD needs it to setup the RTT link.
@fanoush Can you share RTT confif steps for Infinitime and OpenOCD?

My first goal is to develop a common touch driver interface so that P8 and PineTime can work the same way with different touchscreen chips, so this all is pretty P8 related ;)

[fanoush]

Can you share RTT config steps for Infinitime and OpenOCD?

check this https://ferrous-systems.com/blog/gdb-and-defmt/#defmt-print
basically you can either figure out exact address from the binary or let it search whole ram (0x20000000 65536)
or see end of https://openocd.org/doc/html/General-Commands.html#Real-Time-Transfer-_0028RTT_0029

[nica-f]

Ah! Oh! Using NM that was not too hard indeed and it finds a control block now!
Can this change from build to build?
Anyway, this is now working, which is pretty cool, telnet'ing into it I am now getting a bunch of messages which wil now help tremendously in figuring out what's going on with the touch events.
Thanks a lot @fanoush !

[fanoush]

Can this change from build to build?

yes, it is static array so ends up where linker puts it, but it does not need to be exact, it searches for it in RAM in the range you specify

[JF002]

In Infinitime though I seem not to be able to find a way to define which debug output to use? Is only RTT supported right now? Or is it possible to enable semihosting output somehow?

The original developer of the bootloader worked with an STLinkV2 and OpenOCD and implemented semihosting support. On the other hand, I work most of the time with my JLink debugger and implemented JLink RTT for debugging. It should be possible to add support for semihosting in InfiniTime, but someone will have to do it ;)

BTW Segger RTT is working also in recent openocd with any swd debugger and is lighter than semihosting so maybe having just that is not so bad.

This is really interesting! I'll definitely have a look!

[Riksu9000]

P8 support would be nice to have officially in InfiniTime. I have some questions about the initial installation.

Sounds like it is possible to flash without ever opening the device, which is good, however DaFlasher seems to be required for it. I couldn't find the sources for DaFlasher. Is it not open source? Are there other options without opening the device?

Is it possible to simplify the installation further, since it seems like the current method first installs wasp bootloader #62 (comment)?

Sounds like there are different P8 versions. Is it easy enough to identify the version, if they need specific firmwares? Are there significant differences other than the accelerometer and is it easy enough to recover if wrong firmware was flashed?

[StarGate01]

I investigated a bit why pinetime-mcuboot-bootloader (I used the P8 fork by @ildar) fails to load on the newer P8b (mine identified itself as MOY-TON5) revisions.

• Apparently these models use a different SPI flash chip: Mine has a P25Q32H, which has a different SPIFLASH_MANUFACTURER (0x85) and SPIFLASH_MEMORY_TYPE (0x60). The bootloader checks these parameters at runtime, and fails if they don't match.
• I had to disable the LF clock (remove MCU_LFCLK_SOURCE: LFXO), otherwise the bootloader would hang in hal_system_clock_start, and would wait for NRF_CLOCK->EVENTS_LFCLKSTARTED, which somehow never happens. I don't know if this is because there is no physical low frequency oscillator on the board, or because of some other configuration reason.

Even with these two patches applied and pinetime-mcuboot-recovery-loader-image-1.3.0.hex flashed (built from @ildar InfiniTime P8 fork), the bootloader still loops. NRF_POWER->RESETREAS tells me that the watchdog reset the chip, which leads me to believe that the boot process hangs as some point and locks up the CPU. I was unable to find where the lockup happens, hal_system_start gets invoked as is should. I suspect it might have something to do with the SPI bus.

Small update: After setting MCU_LFCLK_SOURCE: LFSYNTH, the watch seems to be able to start the application payload. However I don't know how stable this is, as it only worked on the second try. The bootloader manages to boot the main application which was loaded via DFU using the recovery. For this, a blue-cone-cycle (i.e. image swap) has to be performed to load the DFU package from the SPI flash into the CPU ROM.

Does anyone have any ideas concering the low frequency clock?

[StarGate01]

I have published my findings concerning the P8b variant and also some (very beta) binaries at https://github.com/StarGate01/p8b-infinitime .

[fanoush]

Does anyone have any ideas concerning the low frequency clock?

https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/clock.html?cp=4_2_0_18_1#concept_xkj_np1_2r

the internal RC oscillator = LFRC is best choice when external one is missing

[StarGate01]

I have successfully adjusted and compiled InfiniTime version 1.8.0 for the P8b. Added proper support for the C7A20 accelerometer and the CST716 touch driver, the accelerometer is used to generate tap to wake events because the CST716 cannot be woken from sleep.

I have only tested this on my opened P8b, so be careful. The download is here: https://github.com/StarGate01/p8b-infinitime/releases/tag/v1.8.0.0 , and the changelog is here: https://github.com/StarGate01/InfiniTime/commits/p8b. Eventually I want to upstream my changes to Nimble as well as InfiniTime, but I want to validate the patches on a genuine Pinetime first.

To compile for the P8b, Cmake now accepts -DTARGET_DEVICE=P8 -DLF_CLK=RC -DDRIVER_ACC=SC7A20.

[tt1pjm]

Excellent work getting those changes made for P8b. I've recompiled with -DTARGET_DEVICE=P8 -DLF_CLK=XTAL -DDRIVER_ACC=BMA421 to test on original P8. Could only OTA update using GadgetBridge and then encountered only first swipe working which is the same as when new touch handler was introduced. This seems to be caused by incorrect detection of CST816S (mine is definitely a CST716) so I tested making sure CST716 was the loaded variant and this has resulted in being able to perform multiple swipes but single tap still does not work.

[StarGate01]

Interesting. What is displayed in the system information as the touch sensor ID (last line)? Long press button, and then swipe up should work to open up the system information, without needing taps.

I am currently debugging some strange issues concerning the Cst816S on the genuine pinetime, that might be related. These chips might not always be and behave like the datasheet says (or even as they are marked).

[tt1pjm]

Cst716-0.1, but that would be because I hard coded the Cst716 part into variant. I've also noticed that when screen dims before switching off that a single tap will restore brightness even though I can't tap an individual item.

[tt1pjm]

Behaviour is definitely CST716 as swipes only take effect after release of touch.

[StarGate01]

@tt1pjm I guess you modified ReadDeviceIds? It would be interesting to see what your chipId is. I have a pinetime dev kit that has a chip that behaves the same has also a bugged chipId.

If you want to, you can catch me on Matrix at @StarGate01:matrix.org or on Discord at StarGate01#6277 .

[jcmb42]

Excellent work getting those changes made for P8b. I've recompiled with -DTARGET_DEVICE=P8 -DLF_CLK=XTAL -DDRIVER_ACC=BMA421 to test on original P8. Could only OTA update using GadgetBridge and then encountered only first swipe working which is the same as when new touch handler was introduced. This seems to be caused by incorrect detection of CST816S (mine is definitely a CST716) so I tested making sure CST716 was the loaded variant and this has resulted in being able to perform multiple swipes but single tap still does not work.

I happen to have three P8 watches with the same behaviour. How would one read the ChipId?

I already opened one of them and also have SWD access if that'd be of any help.

[StarGate01]

@jcmb42 Hold the side button for a few seconds, then the info screen pops up. Slide up to reveal the hardware information. My devices show for example:

Pinetime devkit:

• Accel. BMA421
• Tch. Cst816S-0.1

P8b (magnetic bay charging):

• Accel. SC7A20
• Tch. Cst716-6c.5

What charging method does your P8 use? A clip or a magnetic bay? What values does it report for Accel and Tch?

If you have opened your watch, what is marked on the actual chip package itself?

As for debugging, please contact me via Matrix or Discord. Thank you!

Also, if somebody wants to sell one of these misbehaving watches, please let me know, I cannot find them online anymore, only P8bs seem to be in stock.

[jcmb42]

@StarGate01

When using your 1.8.0.1 release my P8 device shows:

Accel. ???
Tch. Cst816S-0.2

Original stock firmware info had displayed:

P8a
MOY-TFK5-1.7.7
D35EBE5D
T0-B40002

It has definitely a built-in CST716 (see attached image) and is most likely running a BMA421 acceleration sensor.

I was wondering if I could read out more details using I2Cscan, but didn't succeed in doing so (at least with micropython or espruino).

Swiping only works once as @tt1pjm already stated. It's got one of these god-awful clamps instead of a magnetic charging bay. I bought it around early to mid 2020.

[StarGate01]

@jcmb42 Thanks for the report, this appears to be the same model as @tt1pjm has, which I call P8a. The touch sensor behaves like a Cst716 in fused gesture mode, but reports as a Cst816s. Interestingly, the chip in my P8b reports and behaves like a Cst716, yet the chip is marked Cst816.

I have added an additional binary to my release (https://github.com/StarGate01/p8b-infinitime/releases/tag/v1.8.0.1) for the P8a, which was compiled using -DLF_CLK=XTAL -DDRIVER_ACC=BMA421 to better match the P8a hardware. Give it a try, it should fix the accelerometer support.

I am still looking to buy one of these older P8a watches, if anyone knows of a vendor or has a spare one, let me know.

[StarGate01]

Thanks to @jcmb42 I acquired a P8a watch, and was able to debug the touch controller on that variant. I released a new build of my firmware fork, which includes fixes and configuration options for the P8a. https://github.com/StarGate01/p8b-infinitime/releases. Long story short, the chip ID and chip markings are no reliably indicators for how the chip actually behaves. I also had to patch the LVGL wrapper to accept single-event taps.

Tap to wake is not working yet, because I have not yet managed to implement interrupt support for the BMA421 acceleration sensor.