How to debug FIFO_FULL?

While running code with half a dozen intervals running, the following message was printed:

New interpreter error: FIFO_FULL

How do I determine what caused it, what functionality broke, and how to prevent it from happening again?

This is the code that I'm running:
https://github.com/SpenceKonde/AzzyProje­cts/blob/master/GraphProject/DeskControl­ler/DeskController.js
But i have no watches set, so what could generate this error in this code???

It's running on an Espruino Board clone (the one I posted about in projects months ago) with the D-spec chip for the slightly larger RAM. But it should be working like a normal Espruino Board...
I haven't switched to the save on send to run functions from flash yet - but would that even help? It's FIFO not RAM that's filling up.

Since I do my own builds, can I make the FIFO bigger? With the D spec part, I should have the ram for it, especially once I switch to do save on send.

I'm a bit concerned, since I still haven't started the code to drive the nixies, monitor RF messages (the heavy lifting gets done by an arduino that takes commands and outputs data via serial, since arduino is very good at that and espruino isn't so great at it), or do the userinterface for manual control via the keypad and VFD display (the latter is also serial, via an attiny4313 helper). And it's getting FIFO overflows when I don't even understand what in there could be stuffing lots of stuff into the FIFO.

Running v2.00 of Espruino.

Note: I can't find any functionality that broke.....

I'm afraid tracking down the FIFO error could be tricky. Basically on STM32 the stuff that puts stuff in the FIFO is:

• USB Serial
  
• Normal Serial ports
  
• setWatch
  
  

And really that's about it. I guess the obvious thing is how much data is AzzyRF sending your board?

To do some debug, you could try clearing the flags with E.getErrorFlags and then check them again after any long-running functions you have - you might be able to find a function that runs so long that it's causing the overflow.

Or... it could be that you have code that is sending a lot of characters on serial? If so, that could be blocking the function that's sending and then causing you issues?

But yeah, you can increase the buffer size up to 256 (which uses 1.2k-ish of RAM) here: https://github.com/espruino/Espruino/blo­b/master/scripts/build_platform_config.p­y#L322

That might help? Although if your code is spending all its time busy I guess you might still end up hitting issues.

AzzyRF is not connected at all, and no serial handlers have been defined for it.
No watches set except on the keypad, which isn't being touched.
So either there's a problem with keypad (though I have no indication that onkey() is being called), or somehow there's an overflow from what it's printing to the USB console (which I didn't think was ever very much data)....

Hmm, that's a tricky one. Since you have the build yourself you could look in the listing file, find the address of the ioBuffer variable, and then peek to see what's filling up the IO buffer.

var IOBUFFERADDR = 0x200xxxxx;
// check gen/platform_config.h and set IOBUFFERMASK correctly
var IOBUFFERMASK = 127;
for (var i=0;i<=IOBUFFERMASK;i++) {
  print(peek8(IOBUFFERADDR*i+5)&63);
}

Hopefully you'll see a lot of one type of number, which you could then compare with peek8(E.getAddressOf(Serial1)+3) - the actual numbers are from IOEventFlags in jsdevices.h