fifo_full / memory_busy

Hi, my Bangle.js 2 sometimes displays "FIFO_FULL" or "MEMORY_BUSY" (see attached screenshot). Things I have installed:

• Latest firmware 2.11
  
• Android Integration (v0.05)
  
• Pedometer Widget (v0.20)
  
• Health Tracking (v0.09)
  
• Gadgetbridge Music Controls (v0.08)
  
  

Any ideas what causes these errors? Is there some kind of log to find out?

Thanks

1 Attachment

I see this when uploading source code vie the IDE

I have the same red MEMORY_BUSY message appearing on my BangleJS2 - latest firmware and pedometer widget showing large numbers like this.

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.

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.

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.

I'm running the Anton clock with battery, Bluetooth and weather widgets. Android integration and Messages are also frequently used, of course...

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.

I have never seen the MEMORY_BUSY error, just the FIFO_FULL when I upload a file using the IDE.

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.

Under what conditions does MEMORY_BUSY get shown? Seeing it a bit more often. I'm typically running 3 widgets and clock.

MEMORY_BUSY happens when something is happening to the variable store which keeps it busy (that usually means garbage collection) and a new variable is requested from inside an interrupt.

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.

I had a brief period a fewweeks ago when I'd seeMEMORY_BUSY a few times a week, but have not seen it at all since my last message in this thread (14 days ago).

I have had this too, both MEMORY_BUSY and FIFO_FULL.

Everytime I use "GPS Info" to try and setup a GPS connection (which never succeeded) I get the FIFO_FULL. The weird thing is, I am just connected to my phone, not to the WebIDE or something else which sends data.

MEMORY_FULL also looks like it appearing randomly. I did compact the data a few times using the Utils menu, but it still happens a few times a week.

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?

Everytime I use "GPS Info" to try and setup a GPS connection (which never succeeded) I get the FIFO_FULL.

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.

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

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.

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.

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.

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.

You can use E.getErrorFlags() to see if the error flag was set... My gut feel is memory busy might be something like the pressure sensor, or something with a promise that completes outside of the main execution loop.

I had a look and also found E.on('errorFlag', function(errorFlags) { ... }); Was thinking there might be a way of dumping a stacktrace to work out what prompted the MEMORY_BUSY, but then realised that the context would be lost by the time E.on('errorFlag',) has been received.

I see MEMORY_BUSY every now and again when running my Pastel clock. As far as I know I am not doing anything particularly heavy etc. Could this be caused by code that might cause a memory leak (I dont think Pastel has a Memory leak), just cluthing at straws really.

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.

It's a hard one. I recently found an issue that caused NRF.setAdvertising to create a 'memory busy' error.

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 process.memory() which triggers a GC pass then it's far more likely that you get the error - things like the memory widget will do that a lot

Aha, Pastel calls process. memory every draw, 60 seconds, I did not realise it schedules a GC as well Is there a way to get current memory usage without triggering a GC? If not I will take this out of Pastel.