Espruino on your watch!

Posted on
Page
of 6
First Prev
/ 6
  • That's a shame - very surprising about the lack of memory mapping. I wonder whether there's anything that can be done to trap memory access areas and effectively page in code as it's needed?

    I think without any built-in functions you could get the interpreter into 96k (especially if you could drop floating point support). You could then make the interpreter load built-in functions from flash into RAM and execute them on demand (but that'd probably require all the functions to be compiled with position-independent code).

    Thing is, that's going to be a hell of a lot of work I'm afraid, and even after that you won't have much RAM for code :(

  • That's a shame - very surprising about the lack of memory mapping.

    Yes, they simply expect everything to fit into SRAM including code. There is boot ROM which loads code from OTP ROM or SPI or UART into SRAM. I guess it is done for power saving (not sure how much flash in NRF5x draws?) and this solution may make perfect sense for lot of typical BLE use cases.

    They also have newer family DA1468x and they enlarged SRAM to 128KB and added XIP from SPI FLASH via additional 16KB cache (similar way how e.g. ESP8266/32 works). But still they have this mode optional and you can also select same mirror mode where you have 128+16=144KB SRAM loaded at boot time or resume from deep sleep.

    Thing is, that's going to be a hell of a lot of work I'm afraid, and even after that you won't have much RAM for code :(

    Yes, I guess so. This older DA1458x family is perhaps not a good fit for Espruino.

    Too bad I did not notice HX06 is Dialog and already ordered more than one. All other Lenovo devices supported in same android app has vendor marked as Nordic but only this one has Dialog there in the config. As it supported same communication protocol and otherwise looked the same I did not notice. Also the FCCID photos did not have cpu markings readable but had SWD pins marked so I guessed wrongly ARM Cortex implies Nordic.

    Anyway I'll try some minimal build just with serial console running and see. However most probably it will be better to port something lighter to this or directly write in C.

  • Just to let you know that I made some progress with DS-D6 fitness tracker. I have build older 1.87 espruino (before this commit) which was still using SDK11 and SoftDevice S132 v2.0 (same as current firmware) . First I flashed it via gdb over SWD but it did not boot and the bootloader stayed in DFU mode. So I tried to find out why and modified stock fitness app to see if there is some failed checksum or something. I found version strings and lowered all parts (100.016.051 to 090.015.050) and reflashed this and it booted just fine. So there is no checksum (at least over whole app binary). However with the lower version the android app told me there is OTA update! So I let it and it updated the device. However after reboot everything worked except display which showed some random pixels and parts of bigger digits showing time. Button and bluetooth still worked and when trying to pair with the app via bluetooth I noticed the watch name changed to DS-D9! So I got firmware for different model! Then I found out the last part of FW version .051/.050 matches manuCode field in /assets/DSBLEBandD.json inside app apk. 50 is indeed DS-D9 while 51 is DS-D6. Also after update I found on sdcard folder /sdcard/Mpow Band/update/ with nordic style DFU zip package with .dat, .bin and manifest.json inside! So while the DFU bootloader does not advertise Nordic DFU service, it is using same update format. Knowing that I used older legacy 0.5.3 nrfutil (matching SDK11) to make package from DS-D6 firmware dump with similar manifest.json as the DS-D9 zip and then tried serial DFU update. And it worked! I got some timeouts and interruptions with black magic probe serial port so I used real serial adapter and it went to 100% and rebooted back into working DS-D6 firmware! So I tried to update back to 'bad' DS-D9 and then back and it all worked as expected.

    And as final experiment I packaged that older 1.87 espruino build that did not boot previously, flashed it via DFU and .... it worked! So now I have both serial and bluetooth espruino console working (with original Desay bootloader and old softdevice) and it is possible without opening the watch :-)

    So now I need to figure out how to rebuild current version with older Nordic SDK and SoftDevice or I better try to upgrade the bootloader and softdevice somehow via DFU. Or if current DFU bootloader does not support updating itself I need to make custom app that will do it. Or possibly I can try first reflash just bootloader to older Nordic one from SDK11 that works with same soft device (possibly via Flash module while running Espruino?) and then proceed with Nordic tools without any custom Desay stuff.

    I updated my wiki here https://github.com/fanoush/ds-d6/wiki/DF­U-update with some details.

  • Just to let you know that I managed to add SDK11 support back to current Espruino source and have working version of 2.00.137 running on top of SoftDevice 2.0 and original Desay bootloader in DS-D6. Also I figured out I can set GPREGRET via poke32(0x4000051c,1) to reboot immediatelly to DFU bootloader so I can restore original fitness watch application back or update to newer espruino, all without opening the watch.

    The SDK11 based build seems to work including bluetooth however initially I had issues with hardware SPI and I2C. I fixed SPI - in SDK11 SPI_ENABLED is not defined but I2C1 still doesn't work correctly for some reason. It returns just zeroes. Software implementation works fine so I just use 'new I2C()' instead of 'I2C1' for now. It is strange however since the HW registers seem to be set up correctly - if I do I2C1.setup with correct pin and speed I see it set up properly when checking TWI1 registers via peek32 starting from 0x40004500. ENABLED has value 5 and PSELSDA,PSELSCL and FREQUENCY is correct too so I'm not sure why it doesn't work and I get just zeroes. Anyway as the SW implementation works it is not such big deal.

  • Forgot to say that if anyone has DS-D6 and wants to try espruino via serial DFU update the espruino_2v00137_SDK11.zip DFU package is here and to get back the watch fitness app the D6-DS.zip DFU package is here

    To perform update nfrutil 0.5.3 worked for me in linux as described here https://github.com/fanoush/ds-d6/wiki/DF­U-update#serial-dfu-procedure

  • @fanoush, for sure... if no circular saw and drill from the dentist required - even though Dremel version of it is available: I'll try it right away...

    You wrote about that it may become possible just thru the USB connector, the one used to charge the module. Is that understanding correct?

    To above package onto the module, I assume, crowbar skills are still required. I have two shots: 2nd has to work. One band is still nicely connecting... the other one just can send the confirm connection to phone not anymore. I assume it has to do with the app or the phone - a not so bleeding of the line Moto.

    ;-0


    1 Attachment

    • DS-D6_band.png
  • You wrote about that it may become possible just thru the USB connector, the one used to charge the module. Is that understanding correct?

    Yes the pinout is in the guide https://github.com/fanoush/ds-d6/wiki/DF­U-update#serial-dfu-procedure I'll also add photo which one is tx and rx but if you know which one is gnd and 5V then the table should be enough even if you don't have proper usb wire colors (I have cut some old USB cable with usb female on one end and those are standard colors).

    And no crowbar skills required unless you manage to go into infinite js loop without watchdog enabled. So using https://www.espruino.com/Reference#l_E_e­nableWatchdog - possibly the variant with false win manual watchdog kicking may help in such case.

    EDIT: The procedure itself is over serial but to enter the bootloader you need to run AT commands via bluetooth console as linked in the guide - I used Serial Bluetooth Terminal android app - it has a way to provide custom service GUIDs for serial service - in the device scan list hold on the DS-D6 device name and select Edit and pick the service UUID with first number ending with 190b.

  • Ic. It is not directly USB (computer) to USB (watch), but USB (computer) to USB-Serial (converter, RX/TX levels set to 3.3V) - USB (watch), latter connection as described in ...#serial-dfu-procedure.

    I'll try first the one that has BLE phone connection issues. It is carried around by my spouse... to count steps... and miraculously: knitting stitches/loops... so easy to fool the step counter. We had a great laugh when we detected numbers of steps she could for sure not have made in the time observed. When knitting, she puts it away to not get 'alternate facts'.

    I'll let you know in a bit (after hitting the sack).

  • It is not directly USB (computer) to USB (watch), but USB (computer) to USB-Serial (converter, RX/TX levels set to 3.3V

    Yes, exactly. Also the serial console in espruino is on same pins, speed is 38400. Or you can use bluetooth - Espruino Web IDE or same android app - just switch the service ids back from custom to nordic style serial.

    Also I wonder how many creative ways people find to lock themselves out - possibly turning off bluetooth (NRF.sleep()) with combination of serial power saving feature is one of them :-)

    BTW, after flashing espruino there is no special DS-D6 code present. You just get espruino serial and bluetooth console. My current WIP code you can use as a start is here https://gist.github.com/fanoush/ce461c73­c299834bcb53a615721b5a2e I just paste it into console. However so far I was mostly figuring out this low level stuff so I did not have time for some real Espruino coding.

    EDIT some photos from updating second (unopened) watch to espruino
    dfu-serial-updating.jpg


  • Strange thing, after updating second watch I am experiencing random espruino restarts with it, this never happened with my first watch, I wonder if you will see it too. I have same build of espruino in my first watch since yesterday and it still shows the time when touched so it definitely did not reboot since yesterday.

    Since I just unpacked it and never used it before I have reflashed it via DFU back to stock fitness app and see how it behaves when using with the mobile app for some time. This is one from my last order from gearbest, white unlabeled box and no FCC markings on the watch, previous boxes have blue mpow logo in the corner and watch has FCC markings.

    EDIT:
    After some more testing looks like even the first watch restarts sometimes when I use it more. May be bluetooth related. Looks like current code build with SDK11 is not stable.
    EDIT2:
    After even more testing it looks like some temporary issue perhaps related to some leftover from running bootloader or DFU update or original firmware because it went away and no longer happens. Both watches are running espruino for 2 days and I am now running

    setInterval(function(){NRF.findDevices(f­unction(d){console.log(d);})},10000)
    

    on both watches for hours, even being connected to one of them via bluetooth console so it is sending the output of the bluetooth scan over bluetooth and it is rock solid. And it also runs my simple clock code (touch button to show date/time/voltage) so in addition to bluetooth it uses HW SPI and button interrupt.

    So if it happens to you let me know and see if it goes away after some time or after draining the battery and clean poweron. It is definitely no excuse to not try Espruino on DS-D6 now ;-)

    EDIT3:
    Looks like it was watchdog, DFU bootloader probabaly enables it. After it restarted the RESETREAS register - peek32(0x40000400).toString(16) prints value 6 so soft rest and watchdog reset ocurred.

  • I have also tried to update soft device and bootloader via DFU and it looks promising. The package is accepted and flashed. Softdevice 2.0.0 to 2.0.1 upgrade works. It (always?) overwrites application space no matter what the package is, so after softdevice DFU package I needed to use application zip again and it worked. I also made single package with softdevice 3.0 and current espruino bootloader (luckily it uses same starting address and bootloader settings address as original bootloader) and it seems to be flashed correctly however it appears to try to start (missing) application immediately and does not stay in DFU update mode. Probably some checks for valid app are disabled there(?). It also goes to DFU mode when button is held at reboot time so I'll try again DFU update while touching the button when it ends, it may work.

  • I'll let you know in a bit (after hitting the sack).

    So did you try?

  • EDIT:removed misleading stuff about interrupt vector names, after checking result with objdump that change didn't help, it worked fine without changing anything there.

    Anyway HW i2c seems to work now in SDK11 based build.

  • @gordon welcome back, would you accept fixes for building with SDK11 again? It is just few missing #ifdefs in code and a bit more ifdefs in make/family/NRF52.make make/common/NRF5X.make and also whole targetlibs/nrf5x_11 resurrected back from old days. I see there is also sdk14 and 15 in the tree, are you trying just to move to latest one and current state with multiple sdks is just temporary until latest works or you are keeping more for reasons?

    From release notes of SoftDevice it doesn't look like current 3.0 used with SDK12 has so much added in functionality when compared to 2.0.1 and it is so much easier to update just application in the watch and stay with stock bootloader and softdevice and there seems to be no downside - even more flash and ram is available. So I may just maintain a fork as long as possible/needed if you don't wish to bother with SDK11. However you already have plenty of '#if (NRF_SD_BLE_API_VERSION >= 3)' there so with few fixes it is still good for BLE API 2 / SDK11.

  • Unfortunately Nordic stopped supporting nRF51 after SDK12 so I'm always going to have to keep builds for that going as long as I support nRF51, but the plan is eventually to support SDK15 as well.

    Having said that I'm fed up having the repo full of Nordic SDK libraries so I plan to move towards putting the newer SDKs in https://github.com/espruino/EspruinoBuil­dTools and using the provision script to pull them in and apply patches as we do for ESP8266/32 - so really if there was SDK11 support I'd want to do it that way.

    How many ifdefs are you talking about? Nordic have told me in the past that SDK11 does have some bugs, and from my point of view there doesn't seem to be a great reason to support it if doing so is going to cause me any future headaches at all.

    Can you think of any good reasons to support it other than your use-case of wanting to use an older device without having to spend an extra 5 minutes of DFU time as well?

  • How many ifdefs are you talking about?

    The whole diff is here https://github.com/fanoush/ds-d6/blob/ma­ster/espruino/SDK11.diff most of it is in makefiles. bluetooth used call from API 3 without check and in jshardware.c there are couple of ifdefs and macros that differ.

    I'm fed up having the repo full of Nordic SDK libraries so I plan to move towards putting the newer SDKs in https://github.com/espruino/EspruinoBuil­dTools

    Sounds good :-)

    Nordic have told me in the past that SDK11 does have some bugs

    sdk is bunch of sources so they can be fixed if they documented it (unless it is inside softdevice, for that there is 2.0.1 with some bugfixes), so far it works just fine

    Can you think of any good reasons to support it

    well there is a bit more ram and flash free so if no advanced BLE feature is needed the rest works the same

    your use-case of wanting to use an older device without having to spend an extra 5 minutes of DFU time as well?

    as there is no reset button and the update of bootloader and soft device is quite invasive there is risk of 'bricking' it, so far I did not succeeded to produce working DFU update package. Your version of bootloader hangs for me now after DFU update (possibly happily jumping to missing application?) I am working on bootloader that would work when upgraded from old one. Your Espruino bootloader works fine when flashing as part of whole hex via SWD but not when used as part of DFU package for old bootloader.

    So it is not just extra 5 minutes but also building working bootloader possibly with oled support and dual BLE/serial DFU like the old one. Also I am not that happy with signing everything with espruino key (which can get lost after years), current old bootloader accepts everything.

  • Your version of bootloader hangs for me now after DFU update (possibly happily jumping to missing application?)

    Oh, looks like it is not the bootloader itself. Looks like original Desay bootloader does not handle DFU package with softdevice and bootloader combined correctly. Funny thing but it does overwrite itself correctly with new bootloader but for some reason it does not update softdevice 3.0 or 3.1 correctly. It almost does, all data between addresses 0 - 0x1f000 is almost fine except one part between 0xE000-0xE7FF where after DFU update is just 0xFF. Which is pretty strange because it does handle softdevice update 2.0.0->2.0.1 where same locations are updated correctly. I tried it many times with different packages and the location is always cleared like that despite the package having something else inside. So after such DFU update it does not boot but it is enough to load softdevice hex again via SWD debugger and this area gets filled with correct data (which is the only difference) and then it boots into DFUTarg correctly. Also just softdevice or just bootloader update does not work, both combinations crash as they are not compatible. So my only idea is to make my own intermediate bootloader from SDK11 Nordic sources (so it works with same soft device), flash just that and then try again with combined package to go to SDK12/softdevice3.x.

  • Just to let you know that I managed to get also DS-D9 bracelet . This is the one I got firmware update for by mistake when I modified DS-D6 version/model number inside firmware and after update it worked inside DS-D6 except display layout. And indeed it is almost the same as DS-D6 internally, same pinout. Same espruino code works, flashed over serial without opening it, still figuring out display memory layout (SSD1306, probably 64x32). Too bad it is even harder to get than DS-D6. However I like its minimalistic design. Got black one. The seller is here but already raised price (I got it for 11.99) and went out of stock.

    EDIT: from FCC's "Declaration Letter of Model Difference" it says that DS-D9 is identical to Lenovo HW02 (Plus). This one is sold in many places and indeed looks the same but the price is just insane for what is is (small OLED).

  • Nice - thanks for the link!

  • still figuring out display memory layout (SSD1306, probably 64x32)

    Took me some time to figure out and I didn't believe it. The resolution is 72x40 and the correct SSD1306 flip command is [0x21,28,99,0x22,1,6] so the visible memory is somewhere in the middle. After googling the resolution I finally believed 72x40 SSD1306 is a thing
    Espruino on DS-D9

  • Wow, strange - but that is extremely cool!

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

Espruino on your watch!

Posted by Avatar for Gordon @Gordon

Actions