fifo_full / memory_busy #6925
Replies: 1 comment
-
Posted at 2021-12-23 by HughB I see this when uploading source code vie the IDE Posted at 2021-12-23 by blogmywiki I have the same red MEMORY_BUSY message appearing on my BangleJS2 - latest firmware and pedometer widget showing large numbers like this. Posted at 2021-12-23 by HughB I don't think its specific to Apps I suspect its related to the IDE. I see it on about 50% of file uploads through the IDE. I just do a reset before I test. . Never happens when using the App loader. Its an annoyance but not a major issue. Posted at 2021-12-23 by johan_m_o I've seen that randomly (just everyday use) on the watch since updating to 2v11.251. Haven't had time to troubleshoot yet... Will turn on debug messages and see if anything pops up. Posted at 2021-12-23 by HughB Never seen it in daily use apart from uploading files. What are you generally running most of the time ? Unlikely that you are running low on RAM on a B2. Posted at 2021-12-23 by johan_m_o I'm running the Anton clock with battery, Bluetooth and weather widgets. Android integration and Messages are also frequently used, of course... Posted at 2021-12-24 by leiropi I also see it randomly, while not connected to the IDE / App Loader. Most of the time my bangle is connected to Gadgetbridge running on my phone. Posted at 2021-12-24 by HughB I have never seen the MEMORY_BUSY error, just the FIFO_FULL when I upload a file using the IDE. Posted at 2022-01-05 by @gfwilliams The FIFO_FULL issue is when more data gets sent than Bluetooth can handle. The Web IDE does implement flow control but it's possible that on some platforms there's enough of a delay for data transmission that the buffer can overflow. I guess I could lower the point at which the flow control is toggled to help avoid this. With Gadgetbridge, there is no flow control BUT it's a patch I have that I'm hoping to get in to Gadgetbridge soon, so it should hopefully avoid these kinds of issues. I'd have thought it would be very rare (more than ~1kb of data needs to be sent in one go) but maybe if you have some big notifications that could trigger it. Posted at 2022-01-05 by HughB Under what conditions does MEMORY_BUSY get shown? Seeing it a bit more often. I'm typically running 3 widgets and clock. Posted at 2022-01-06 by @gfwilliams
That should be extremely rare especially on Bangle.js 2, so it'd be great if you could find a way to reliably reproduce it. It's possible you have some app that is forcing a garbage collect which is making it more of a problem though? On Bangle.js 2 GC passes should be super rare given the amount of RAM available. Posted at 2022-01-06 by johan_m_o I had a brief period a fewweeks ago when I'd see Posted at 2022-01-15 by jeroenpeters1986 I have had this too, both Everytime I use "GPS Info" to try and setup a GPS connection (which never succeeded) I get the
I do have the Bangle.js2 btw, with firmware v2.11 (not bleeding edge), 12000 JS Vars and 7800+k free Is this something I need to take action on, or just reload? Posted at 2022-01-16 by HilmarSt
FIFO_FULL is solved (90%) in GPS Info version 0.09: Fix FIFO_FULL error For "GPS connection (which never succeeded)" you should try "Assisted GPS Update (AGPS)" in the App Loader. Posted at 2022-01-18 by @gfwilliams I don't think this is something to worry about at the moment. FIFO_FULL is hopefully fixed in the GPS Info (but also in absolute latest firmwares I've disabled that warning as it wasn't any real help). MEMORY_BUSY would be good to know if you find a way of reliably reproducing this, but again it's nothing to worry about Posted at 2022-01-29 by myownself I've just seen Memory Busy. No non default widgets, running the Pastel clock. RAM was at 17% which is what it seems to be at most of the time on the clockface. Posted at 2022-01-29 by HughB I have seen this sometimes as well with the Pastel clock. Usually after I have been uploading files through the IDE. Cant find a pattern to it to easily reproduce. My gut feel is it could be something to do with one of the custom fonts but that could be rubbish. Posted at 2022-01-29 by myownself Interesting. Earlier in the day I had been running some code from the IDE, just playing around a bit, but the message showed up hours later. It is possible I had done something else in the mean time though, I am finding I manage to unlock and launch apps accidentally even with button press being the only active wake method. Probably because I wear on my right wrist. Edit: just saw this again, and definitely haven't been using the IDE since the watch was last rebooted. I've had the clock open, and I've had the 15 puzzle open. Posted at 2022-01-29 by HughB I wonder if there is a way to wrap some of the code with try catch and see if there is a cause and effect or its something else. Posted at 2022-01-31 by @gfwilliams You can use Posted at 2022-02-04 by HughB I had a look and also found I see Posted at 2022-02-04 by myownself I saw it a few times with Pastel, then I switched clocks to 93 Dub and didn't see it again. But I don't know what in Pastel could be doing it. Posted at 2022-02-07 by @gfwilliams It's a hard one. I recently found an issue that caused If it helps: 'memory busy' means something running in an interrupt requested a new JS variable and one couldn't be provided because the main thread was using the variable store (most likely for Garbage collection). So... If you keep calling Posted at 2022-02-07 by HughB Aha, Pastel calls Posted at 2022-02-07 by @gfwilliams Yep, that'd do it. Although it still brings up the question of what is allocating memory in an IRQ - which is something that probably needs looking at. Is Pastel clock using any sensors apart from accelerometer? In the cutting edge releases you can now do Posted at 2022-02-07 by HughB
Not to my knowledge. It does not use the accelerometer either.
It gets steps from
Great. Will do an update to Pastel Clock to get rid of the GC possibility. Posted at 2022-02-08 by @gfwilliams Thanks! What you've got there looks fine though. It's a strange one... Posted at 2022-05-12 by Poolitzer I see this error regularly on my Bangle JS 2, mostly stock and no Bluetooth connection. Posted at 2022-05-13 by @gfwilliams Interesting it happens for you without a Bluetooth connection.
This is the problem though :) none of the 'stock' Bangles I have running here do this, so it must be something you installed. I guess you could do a 'backup' of your Bangle and I can restore it to a Bangle here and see if I can reproduce. Posted at 2022-05-24 by Poolitzer I received my new bangle because the old ones bluetooth had issues. Should I send the old one, which quite reliably shows this error, back to you? Or can I backup the bangle with the debug ports? Posted at 2022-05-25 by @gfwilliams It'd be great if you could send the old one back, yes. Then at least we can attempt to get the manufacturer to fix it, or at minimum try and see why there was the error. In theory connecting via the debug port may be possible, but because your data is saved on memory that is not part of the chip, reading out saved data is pretty tricky. It's not something I have attempted. Is there specific data on the Bangle that you need? Posted at 2022-05-25 by Poolitzer No just for you, in case the bangle gets lost in the mail. Alright, I will see to sending it back. Posted at 2022-05-25 by @gfwilliams Great, thanks! I think more likely than not it'll be a hardware issue rather than software though Posted at 2022-08-08 by rocky Did this patch make it in? I'm seeing this error when receiving large http responses (16-20kB) from the openweathermap api through gadgetbridge. Posted at 2022-08-09 by @gfwilliams Which message are you getting? Fifo full or memory busy? If you try the cutting edge builds, some changes went in since 2v14 to improve the memory_busy situation. In terms of fifo_full it could likely be because I'm not sure if Gadgetbridge implements any flow control right now (I have it on a branch but the changes messed deeply with code that is common to other watches so it's not merged yet). If you just turn off the 'increased MTU' in Gadgetbridge settings it'll probably fix it though Posted at 2022-08-10 by rocky I've seen both actually, though the memory_busy seems to come up if it has been idle for a while. I read another post of yours explaining memory_busy:
In my code, each time the weather is updated, I have to create some fairly large objects: first parsing the JSON http response, then cherrypicking the interesting data from the JSON into my own structure. Could this be what is triggering the garbage collection? I probably need to switch to a more efficient way to store it, like you describe here: http://forum.espruino.com/comments/14667057/ For the FIFO_FULL, I already had "increased MTU" turned off. What branch is it on? I wonder if we could improve the transfer efficiency for APIs with JSON responses (what I imagine most people are using Bangle.http for) by either heatshrinking them and/or pre-decoding the JSON within GadgetBridge and transferring the equivalent of a Python pickle? Posted at 2022-08-11 by @gfwilliams
Maybe - could you try cutting edge builds and see if that helps though. I imagine the MEMORY_BUSY stuff will go away. FIFO_FULL happens when more data comes in than Bangle.js can handle - and in fact the issue may just be (without flow control) that you have a clock face that takes a long time to update. If it drew faster Bangle.js would be able to handle the data at the rate it comes in.
Yes. Personally I think the best solution there is really just to implement an XPath for JSON, inside Gadgetbridge. I believe there is a 'JSPath' implementation that could be pulled in - it seems crazy to send 20k of data over bluetooth when realistically all you care about is maybe 40 bytes of data. Posted at 2022-08-11 by rocky
In my case, I need, if efficiently packed before being sent to the watch, about 400 bytes, representing 48 hours of weather data. I think in an ideal world, I would have a small program on the phone side (perhaps an embedded Espruino interpreter?) that handles the packing of that data, and then forwards the 400 bytes back to the watch. I think this is basically what "pebblekit for javascript" was designed for, though I don't think anything like that is implemented currently in gadgetbridge? Posted at 2022-08-12 by @gfwilliams
Well, Gadgetbridge does provide some Pebble support, but I'm not sure how easy it would be to repurpose that. That's an interesting thought though - rather than trying to include JSpath you could just include some JS to run inside Gadgetbridge. I'm not sure how sensible it'd be to run Espruino, but Android does seem to have a few ways of running JS Posted at 2022-08-12 by rocky Yeah, and it would certainly be more flexible. Imagine any sorts of tasks that would take a prohibitively large amount of ram or processing time if done on the watch. I think what we're describing here are what remote procedure calls are? Maybe we could leverage an existing RPC framework? The reason I suggested embedding espruino was for the superficial benefit of having the same internal representation of data in both the phone and watch, though that small benefit is erased if we're serializing/deserializing the messages in a separate lib. Posted at 2022-09-22 by user91203 I get MEMORY_BUSY regularly. Pretty much any time I pick up the watch to put it on it will be showing that message.
Posted at 2022-09-22 by @thyttan Do you have a Bangle.js 1 or 2? Posted at 2022-09-22 by user91203 This is Bangle.js 2. I never saw the message on my 1. Posted at 2022-09-23 by @gfwilliams And you're on the latest firmware? This could be the I thought I fixed this on 2v15 firmware though. But maybe you could try uninstalling it for a bit and see if that fixes the problem. If it does, I can have a look with it here and see if I can manage to debug exactly what's going wrong Posted at 2023-02-20 by Hank I still get the fifo_full error more and more. Any Ideas? Posted at 2023-02-22 by @gfwilliams Is it the app from the play store, or the F-droid nightlies? I think the Play Store one still doesn't have flow control enabled Posted at 2023-02-22 by Hank It's the Play Store app. Posted at 2023-02-23 by Hank Changed to the f-droid apk and no fifo_full so far. Knocking on wood. Posted at 2023-02-23 by iii Do you plan to add flow control to the play store version as well? Unfortunately, my doesn't device doesn't allow third party store installations. Posted at 2023-02-23 by @thyttan Answer here 🙂: https://forum.espruino.com/comments/16880098/ Posted at 2023-02-23 by @gfwilliams
Yes - I talked about this in another thread but Google changed the Play Store rules to we had to change the 'API version' when uploading updates, and that potentially causes other issues with Gadgetbridge so it all needs to be checked out thoroughly - otherwise I risk breaking everything :) Posted at 2024-05-15 by user158154 Running latest Gadgetbridge 0.80.0-banglejs from F-Droid and latest Firmware 2v21 on my Bangle2. Since some weeks(?) I see these two annoying messages "FIFO_FULL" and "MEMORY_BUSY". My collection of apps is unchanged since a long time - so could be related to some recent updates ... Any advice? Posted at 2024-05-15 by @gfwilliams Well, the two errors are a bit different:
Posted at 2024-05-16 by @gfwilliams Just a note that I may have finally fixed the remaining MEMORY_BUSY error on cutting edge builds (the fix will be in 2v22). It was related to the Health event that occurs every 10 minutes - it had to check daylight saving time to see if it was midnight or not, and it seems that caused the issue Posted at 2024-05-22 by Hank I actually got the fifo_full again every other night when I switched to my new S24 Ultra. Using the latest F-Droid GB. Large MTU is disabled. Posted at 2024-05-22 by @gfwilliams The fifo_full isn't related to my memory_busy fix. If you can get any Gadgetbridge logs that would be handy - there should ideally be Posted at 2024-05-23 by Hank @gfwilliams log file see PM. Posted at 2024-05-23 by @gfwilliams Thanks! I've just got the log and taken a look at it The FIFO_FULL has happened while trying to sync your calendar. It seems like it probably won't cause a big problem as things will resync after a bit and fix any issues, but still it's annoying. It seems XOFF is sent by Bangle.js in one message, and then received by Gadgetbridge, but pretty much immediately we also get the FIFO_FULL message (despite it taking another 1500 bytes/75 transmit calls) to fill up the buffer (Gadgetbridge would appear to be sending around 4k in one chunk) So what appears to be happening is Gadgetbridge is sending a bunch of data and isn't checking for any responses until it's done, by which time it's too late. I've filed an issue on Gadgetbridge for this: https://codeberg.org/Freeyourgadget/Gadgetbridge/issues/3794 Posted at 2024-05-23 by Hank Plausible. I have a tool that each morning loads an ics, deletes a calendar and loads the data fresh from the ics. Posted at 2024-05-24 by @gfwilliams
Ok, that'll be it then. I can see it pushing ~30 calendar changes at least. The log shows I've just made some changes to Gadgetbridge to make it more likely to honour that setting though (it now ignores CalendarReceiver if calendar sync is turned off) so the next nightly build should have the fix. If you update the Bangle.js Android app from the latest cutting edge it also attempts to sync the calendar in a more efficient way which I'd hope would be a little faster - although it seems like it's not the Bangle requesting a sync - it's CalendarReceiver that's pushing the data to it in which case we don't have much control over it. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2021-12-23 by leiropi
Hi, my Bangle.js 2 sometimes displays "FIFO_FULL" or "MEMORY_BUSY" (see attached screenshot). Things I have installed:
Any ideas what causes these errors? Is there some kind of log to find out?
Thanks
Attachments:
Beta Was this translation helpful? Give feedback.
All reactions