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.