-
Yeh I generally flash from ide (execute code at boot).
I just tried writing directly to .boot0 but having too many glitches to list (it's like it's trying to load the usual Bangle OS as well as my app at the same time, as well as giving me a scrolling screen of bluetooth errors)... do I also need to be modifying and writing the following into the left hand side of the ide:
require("Storage").write("abc.info",{
"id":"abc",
"name":"abc",
"src":"abc.app.js"
}); -
-
“You'll need to delete both of the ifdef BANGLE bits here”
Ah that’s working better… seems I can just press and hold on the splash screen to force my flashed app to boot from that screen (as opposed to looping back to the bootloader).
(my modified code: https://github.com/stuaxe/Espruino/blob/728409948658a4ff11053cb5a1155cb36a1c95b8/src/jsflash.c#L1372C1-L1384C1)And thanks for letting me know about the 30 second time out on the initial bootloader screen (it’ll be much easier to direct the user to simply ‘wait’ if they see that screen).
Is there any way for the splash screen to also get that behaviour (the 30 second time out till loading my flashed app)? If not, is it easy enough to modify the splash screen to include an instruction just to hold the button down until the flashed app appears?
-
"Have you thought about increasing the duration required to enter the bootloader? Are they going to be likely to hold the button for 10 seconds eg.?"
If that is possible then it would be a great solution. But it would have to be an increased duration from the very start of the Bangle booting up (which seems like it would need a firmware modification).
-
"- replacing that feels like a really bad idea, but if you do the other stuff then as long as they don't flatten the battery and hold the button while applying power, they will never see it."
Yeh that's still the use-case I'm worried about... Simply because it takes 'more' than a quick click of the button to turn the Bangle on (I typically have to hold for about 1 second to boot)... so if the user's first attempt to turn it on is too short they might overcompensate with a long press (holding for about 2.5 seconds typically starts the bootloader from off).
I could make a little print off to give to the user before testing with them, detailing what to do if they accidentally trigger the boot loader (they will be with the device for a few weeks unsupervised... and with my app they can expect to need to charge it regularly otherwise the battery will run flat)...
Unless there's some simple modification I can make to the firmware... I'll probably just go with that.
Btw is this expected behaviour for the firmware without the recovery menu?: https://www.youtube.com/watch?v=sDSFhLWgZKo
I notice if I allow the ===> to progress all the way to the end and I KEEP holding the button down , it goes to the Expruino splash screen... (where as if I let it go straight away after ===> fills up it initialises my app) .... but it stays at the Espruino splash screen until I go back to the boot loader. It would be handy if the user accidentally gets to that splash screen it would just know to initialise the app (and maybe that's actually the expected behaviour?).
-
Going back to the original question I'm still getting the screen with: ‘ ===>' if the user holds down the button on start up... it just won't progress to the black and white options menu anymore if they hold it down long enough.
Should have commenting out:
if (jshPinGetValue(HOME_BTN_PININDEX))
recoveryMode = true;prevented the ' ===>' screen from appearing (on startup)? Or was your edit just for getting rid of the black and white options menu?
Might still be a simple mistake on my part.
-
Ah actually opening the BANGLEJS2.zip on a Chromebook gave me the necessary folder. That seems to have worked. Cheers.
I did have another quick question which is whether I could completely disable the watchdog menu (not just when holding the button on startup) by modifying the firmware. I've encountered issuers using:
watchdogInterval = setInterval(() => E.kickWatchdog(), 1000);
So any alternative way to avoid the user being able to access debug/system menus would be great. (can I just comment out more code in the fork?)
Thanks
-
I unzipped BANGLEJS2.zip .... which gives me the unzipped folder espruino_2v20.70_banglejs2 ... I can then rezip it to give me espruino_2v20.70_banglejs2.zip ... but trying to upload any of these to the IDE gives me "Error: Unable to find manifest, is this a proper DFU package?".
I've noticed I get the same problem downloading the BANGLEJS2 file (the Artifact Produced during runtime) even from Gordon's GitHub repo https://github.com/espruino/Espruino/actions/runs/7709447059
Again there's probably something obvious that I'm missing.
-
Hi,
I later tried going with the Github method you suggested but encountered a snag when trying to 'Flash from file'. There is probably something super obvious I'm missing as I don't really know my way around Github. These are the steps I followed (see attached images):I tried uploading the .zip artefact file entitled BANGLEJS2.zip to the IDE. I also tried unzipping and re-zipping it.
I noticed a downloaded .zip of v20 from https://www.espruino.com/Download is 520kb but the BANGLEJS2.zip (from GitHub) is 318kb but if I unzip it I get a folder called espruino_2v20.70_banglejs2 which is 514kb and if I compress that it again (with the same folder title + .zip) it is still 318kb. You can see the folder has the relevant .bin .dat .json files and the manifest.json reads:
{"manifest": { "application": { "bin_file": "espruino_2v20.70_banglejs2_app.bin", "dat_file": "espruino_2v20.70_banglejs2_app.dat" } }
}
I'm on a Mac if that makes a difference.
-
Hello,
I’m trying to make my Bangle ‘foolproof’ for when I give it to users to test my app.
I’ve got this bit of code in my app which prevents them resetting it on a long press (and it works great):
watchdogInterval = setInterval(() => E.kickWatchdog(), 1000);
This also prevents the screen with the ‘btn1 = reset ===>’ and the black menu with all the options to factory reset, reboot, restart, turn off, etc.The only issue is if the user let’s the Bangle runs out of power and they charge it back up, instead of ‘clicking’ the button to turn it back on…. they might attempt to ‘hold’ the button down instead… and this may inadvertently get them to the btn1 = reset ===> / black menu screens by mistake…. (as the app hasn’t had a chance to load)
So I was wondering if there was a relatively painless way to just stop these menus / screens from being accessed by the user at all?
Thanks,
Stuart -
"It eats the first press if it was locked or the backlight was off"
Ah, that was my oversight.
This seems to have fixed things:
Bangle.setOptions({ lockTimeout: 0, backlightTimeout: 5000, wakeOnBTN1: false}); function buttonPressed() { console.log("trigger"); Bangle.setLCDPower(1); }
Thanks for your quick replies.
-
Yeh unfortunately changing the lock timeout to 0 didn't resolve the issue... I can't imagine what else it could be (firmware is 2v19 and I'm just using the WebIDE to write to RAM, I also did write to storage). My code is just what I posted. Same issue with what Ganblejs suggested; it does trigger double button presses but only once I've pressed to turn the backlight back on - it really does seem to be behaving like it's locked but it shouldn't be.
In terms of Battery life, my target is to get 2+ days of battery. So something like turning off touch might not be necessary (but if nothing else works it might be a good second option).
I can't help but feel there's something super obvious I'm missing.
-
Hi,
Just a quick question about backlightTimeout...
Bangle.setOptions({ lockTimeout: 99999999999, //1157 days backlightTimeout: 10000 }); //10 seconds function buttonPressed() { // console.log("trigger"); }
The behaviour isn't quite what I expected because when the backlight turns off it takes two button presses to get buttonPressed() to trigger. I'm assuming the Bangle is listening for a button press to turn the screen back on then and then normal behaviour resumes.
This is how I'm handling the button press:
setWatch(buttonPressed, (process.env.HWVERSION==2) ? BTN1 : BTN2, { repeat: true, edge: 'rising', debounce: 50 });I really need it to trigger buttonPressed on the first button press... is there an option that I'm missing, or perhaps an alternative way to handle the button press?
Thanks.
-
Hi, so I’ve managed to get into some bother while playing around with the Web IDE (MacOS Chrome).
I was trying to get around the limitation of being unable to connect the Bangle to iPhone and my computer at the same time… I thought that uploading to Flash (not too familiar with what that means) might allow me to reconnect the Bangle to iPhone.
I lost the ability to exit that app, so did a 6 second reset. But then it didn’t go past this screen:
After this I tried to reinstall the Firmware (I tried several versions; all for Bangle.js 2) from the Web IDE… But the IDE just throws up this error: Error: The state of the DFU process does not allow this operation
I followed all the steps about holding while this ran ====, which brings up the screen with the ‘DFV Start’ text, and selected DfuTarg when selecting which device to pair.
Now I get this screen and not the previous screen from the previous screenshot:
I was wondering what my next steps are?
Is there another way to reset, would that involve a wired connection…? I have access to a MacBook, an iPhone, and I could borrow a Chromebook or Android phone temporarily.Edit: Not sure why screenshots aren't showing but here's the links:
https://imgur.com/HeW3y8v
https://imgur.com/Z7HNmE3Update: Fixed. I was able to borrow a Chromebook and reinstalled the firmware that way (I'd advise others not to use newer Macbooks to flash firmware).
Feel free to delete this thread if not helpful to others.
Would I be able to fork firmware v19...?
I'm not sure if one be suitable: https://github.com/espruino/Espruino/actions/workflows/build.yml
as in which one would be the exact same version that I can download here> https://www.espruino.com/binaries/espruino_2v19_banglejs2.zip