• Heyhey, I just checked my watch and it was frozen on the screen of my last messages, so I held the button to go back to the watchface. And instead of doing that, it went into a boot loop and it's still stuck there (see gif/photos below).

    I can get into DFU mode and then reflash firmware 2.15 and I've done that once through the android DFU app and once through the web IDE, but neither prevents it from going back into a bootloop afterwards.

    Any help is appreciated.


    3 Attachments

    • IMG_20221011_130622.jpg
    • IMG_20221011_130634_01.jpg
    • ezgif.com-gif-maker (11).gif
  • Possibly a file system corruption, specifically of .boot0 or .bootcde ?
    Can you connect to the web ide to get console output?

  • check this https://forum.espruino.com/conversations­/380059/ however before erasing it would be nice if you would be willing to backup your spi flash, I can post instructions, the procedure (transfer 8MB over BLE) may take many minutes (30?)

  • No, I can connect to BLE/webIDE only for a second, and then it disconnects again and I don't see any output.
    In DFU mode, it doesn't connect at all.

  • Sure I can do the flash backup. Lemme know how.

  • OK, thanks, you need to enable terminal log icon in webide https://www.espruino.com/ide/ in settings->general, then start logging by clicking that new icon on left side and confirming start and then paste this code

    var f=require("Flash")
    for (a=0x60000000;a<0x60800000;a+=256) {console.log(btoa(f.read(256,a)));E.kick­Watchdog();}
    

    it will take long time so better put it on charger. After it is done (32768 base64 encoded lines!) stop logging, save output to text file and zip it an upload here or somewhere.
    It is of course important to not break the connection or interrupt the process, the watch will be unusable while logging.

    To get out of the boot loop flash that zip file in that conversation to use internal flash for storage and connect via IDE.

  • in linux you can convert base64 text back to binary via base64 command from coreutils which should be installed by default in any linux distro. Something like this works for me in WSL when first saving the output as text file in windows 10 (with DOS line endings)

    grep '==' backup.txt | dos2unix | base64 -d >backup.bin
    

    grep command filters just base64 encoded lines (lines ending with ==) so there can be also the initial code or any other logged text. if the log is complete the resulting binary file should have exactly 8MB. However you don't need to do this, just zip the text log if possible (to make it much much smaller) and upload somewhere.

  • Sorry about the issues, but thanks for being willing to dump the flash. Hopefully when I have it I can make a new firmware that won't bootloop.

    in linux you can convert base64 text back to binary via base64

    ... but actually if you just post your text file up here that's fine and I can do everything at this end

  • Hm, this is interesting - I can't get more than 15102 lines of log.
    I've tried twice and it doesn't go any further. Am I missing something?
    And lemme know if this is enough or if I can erase the flash and go back to a normal firmware.

    EDIT: Nevermind. I had the setting "save log to localstorage" set to true and that was apparently the culprit. Now it's gone past 16k and still counting. Will post new log here in a minute.


    1 Attachment

  • Here's the full output:


    1 Attachment

  • The log-3.txt.zip looks complete - full 8MB inside.

  • Excellent - thanks! I'll see if I can reproduce the boot errors here

  • ... I'm just uploading now - it's taking a while ;)

    If you want to get it working on the proper firmware, I think: require("Flash").erasePage("0x60000000")­ should allow you to reinstall the default firmware.

    Interestingly looking at the flash dump seems like there's been a compact, but it hasn't wiped all of the flash memory that it freed and it's left some rubbish in there, so that could have been the cause of the problems. I know it was a problem in older firmwares, but since yours was shipped with 2v14 I'd have thought it would have been fine.

    edit: took over an hour to upload, but I can reproduce the boot loop so hopefully I can get a fix in soon!

  • there's been a compact, but it hasn't wiped all of the flash memory that it freed and it's left some rubbish in there

    so can pushing and holding button trigger compact and then (because of still holding the button) watchdog reboot in the middle of compact?

  • Fixed! If you install the latest cutting edge build it should fix that even with your data in flash (but I'm afraid your data seems pretty garbled and I don't think is recoverable).

    It was to do with Storage being corrupted, and then the recent addition of filename tables (to speed up storage) meant that it was using a corrupt file (which was massive) as a filename table, and it spent ages searching it and caused a reboot.

    can pushing and holding button trigger compact and then (because of still holding the button) watchdog reboot in the middle of compact?

    Well, it shouldn't directly reboot - because jshKickWatchDog is called directly from the compaction code. However I just looked at it and yes, a shorter press sets the INTERRUPTED flag, which actually seems to cause the page erase to break out! I'll get a fix in for that now... I bet that's how the most recent storage corruptions happened!

  • Thanks so much for the help, folks! Watch is fixed through the temp firmware + erasePage command. Was able to reinstall the default firmware.

  • Great! Thanks for the flash dump before you did that though - hopefully that'll have meant we improve stability quite a lot going forwards

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

Help - Bangle.js 2: Stuck in Bootloop, DFU update not helping

Posted by Avatar for SloFlo @SloFlo

Actions