Weird serial port shenanigans (MT6261 branch).

[userse31]

Trying to run fernly ("firmware.bin") results in anything that tries to access the watch's (really "phone's") usb serial port hangs/gets REALLY slow. There is no fernly prompt.

Output from running "./fernly-usb-loader -w /dev/ttyUSB0 ./usb-loader.bin ./firmware.bin":

Waiting for serial port to connect: ...
Setting serial port parameters... Ok
Initiating communication... Ok
Getting hardware version... 0xcb01
Getting chip ID... 0x6261
Getting boot config (low)... 0x0000
Getting boot config (high)... 0x0000
Getting hardware subcode... 0x8000
Getting hardware version (again)... 0xcb01
Getting chip firmware version... 0x0001
Getting security version... v 5
Enabling security (?!)... Ok
Reading ME... 00000000 79 04 d2 36 df 84 1e 46 87 95 0f a3 2a 50 b9 ae |y..6...F....*P..|
Disabling WDT... Ok
Reading RTC Baseband Power Up (0xa0710000)... 0x0002
Reading RTC Power Key 1 (0xa0710050)... 0xa357
Reading RTC Power Key 2 (0xa0710054)... 0x67d2
Setting seconds... Ok
Disabling alarm IRQs... Ok
Disabling RTC IRQ interval... Ok
Enabling transfers from core to RTC... Ok
Reading RTC Baseband Power Up (0xa0710000)... 0x0002
Getting security configuration... None.
Getting PSRAM mapping... 0x0000
Disabling PSRAM -> ROM remapping... Ok
Checking PSRAM mapping... 0x0002
Checking on PSRAM mapping again... 0x0002
Updating PSRAM mapping again for some reason... Ok
Reading some fuses... 0x00000000
Enabling UART... 0x0000
Loading Fernly USB loader... checksum matches 0x53ea Ok
Executing Ferly USB loader... Ok
Waiting for Fernly USB loader banner... Fernvale bootloader
Write four bytes of program size, then write program data...

Ok
Writing stage 2... 19348 bytes... 19348 / 19348 Ok
Waiting for ready prompt... Ok

---

This bit in DMESG is interesting.

6,1310,3641289199,-;usb 1-1: USB disconnect, device number 16
SUBSYSTEM=usb
DEVICE=c189:15
6,1311,3641290367,-;option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
SUBSYSTEM=usb-serial
DEVICE=+usb-serial:ttyUSB0
6,1312,3641290388,-;option 1-1:1.0: device disconnected
SUBSYSTEM=usb
DEVICE=+usb:1-1:1.0
6,1313,3653952413,-;usb 1-1: new full-speed USB device number 17 using xhci_hcd
SUBSYSTEM=usb
DEVICE=+usb:1-1
6,1314,3654101095,-;usb 1-1: New USB device found, idVendor=0e8d, idProduct=0003, bcdDevice= 1.00
SUBSYSTEM=usb
DEVICE=c189:16
6,1315,3654101115,-;usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
SUBSYSTEM=usb
DEVICE=c189:16
6,1316,3654107218,-;option 1-1:1.0: GSM modem (1-port) converter detected
SUBSYSTEM=usb
DEVICE=+usb:1-1:1.0
6,1317,3654107478,-;usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0
SUBSYSTEM=usb
DEVICE=c189:16
4,1318,3654108057,-;cdc_acm: probe of 1-1:1.1 failed with error -16

I thought I did the linux acm thing listed in README.md...

The firmware loading IS working though! The vibration test binary "mt6261-test.bin" works and causes the watch to vibrate.

[userse31]

The usb loader stage is also working! Running "./fernly-usb-loader -w /dev/ttyUSB0 ./usb-loader.bin ./mt6261-test.bin" also causes the watch to vibrate.

[userse31]

Yep, "98-fernvale.rules" is in /etc/udev/rules.d/! Even checked the watch's USB id's. They match.

...What about Windows? What if I load fernly on my linux machine, disconnect the USB cable, and then plug it into a Windows machine?

[userse31]

Nope. Windows hates it. Kept getting connected and disconnected as if there was no battery in the watch.

What about the "real" uart lines on the watch? Perhaps fernly will talk using that.

Time to breakout the CH431a!

[userse31]

Nope. Nothing on the uart pins. Though, that's probably down to fernly using the USB uart addresses (is that how that works?).

[userse31]

I've sat on this for a bit. After adding some code that's supposed to activate the vibration motor, it doesn't vibrate.

I don't think there's any code execution happening.

[xobs]

That could very well be the case. It's possible for the vendor to lock out code execution, which might be what's happening here.

[userse31]

Eh...?

After stuffing my nqueens program inside the usb loader stage and sending it to the device, it ran it! The caveat being that the watchdog timer was never disabled, so the watch would reset itself after a short while.

[xobs]

Congratulations!

[userse31]

Thank you! It was incredibly satisfying seeing it run.