Technique needed to notify of low memory condition during runtime

Mon 2020.03.30

This narrative is in response to this answer, but is included here as it contains follow up example output pertinent to the ongoing issue:

'I have never come across a microcontroller with flaky RAM'
Forum post on Sun 29th, March 2020 Is there an exhaustive test to exercise RAM to inspect for flaky cells

I haven't seen a flaky memory cell in twenty years, so I thought unlikely either. But, I had a situation yesterday that nearly identically mirrored the one that caused me to post this thread in the first place.

Remember I had a working code file ~2000+ lines for over a week, running with around 200-300 JsVars free. It was close to being stamped 'done' but needed some minor code cleanup, and the addition of console help.

In post #9 I mentioned I inserted back in a small snippet, expanding the file size, and miraculously the dump errors ceased. So I happily continued for around four hours. Then, Whammo! a similar error response then appeared.

Uncaught ReferenceError: "pulseMarkFreq" is not defined
 at line 422 col 39
analogWrite( pinWaveform, 0, { freq : pulseMarkFreq } );

which is eerily similar to the original

Uncaught ReferenceError: "argsStartup" is not defined
 at line 1145 col 51
console.log( "  STARTUP:  update:  " + argsStartup.update );

which could not have been true, as I just uploaded the code file with the var definition there.
I now understand the reason I didn't locate the cause, and why I started this thread was that the var argsStartup didn't appear in the dump using a visual scan of the console. A search in notepad didn't find it either, as I was looking for the entire string as was the notepad find feature. It would take several days to learn I would find it with a sub-string search.

var argsStartup = {};

Now doing a sub-string search I was able to locate why Espruino is reporting the error, as that var IS NO LONGER THERE!
dump()

var ergsStartup = { "gate": 500, "freq": 200, "update": 1000 };

After initialization, not only does the content of the var location change, the name of the var changes also!!

Using:

http://www.asciitable.com/

I looked up the offending char

a  97  61
e 101  65

but the insight doesn't occur until converted to it's binary equivalent:

a     0‭110 0001‬
e     0‭110 0101‬

I opened this thread. Then when on a hunch I wondered if RAM/hardware was a problem, I posted the link above for an exhaustive test routine.


From post #9 I felt I had a stable situation and moved on. Until the big surprise:

Uncaught ReferenceError: "pulseMarkFreq" is not defined
 at line 422 col 39
analogWrite( pinWaveform, 0, { freq : pulseMarkFreq } );

and found on two separate occassions, but only archive the dump for one:

var pulseMarkFreq = 200;

dump

var rulseMarkFreq = 4;

and looking those up

p 112  70
r 114  72

converted to it's binary equivalent:

p    0‭111 0000‬
r    0‭111 0010‬

It is interesting to note that the changing char is in the fifth location in from the margin, and each discovered case, one and only one bit (but not the same one) is flipping.

I inquired about how dump() actually works at the end of post #8, and have re-inserted it here:

last two pp of post #8

As we (viewers) see the errors within the WebIDE, and this device is wireless, it might be that Espruino running on the device detects an issue in memory, and then reports that to the WebIDE. This would mean that memory on the device is corrupt, and not a translation issue sending chars to the WebIDE that might become corrupt within the WebIDE memory space, during the transfer process.

Does Espruino perform a checksum test on each line of chars that are sent over BT to validate what is received is what was sent? If yes, then this is more likely a parsing/re-assembly issue.

Knowing how dump works is the clue to solving this predicament. Memory is changing at run time, as I have inspected (accurate) a dump, just after upload, checked available memory, observed the var from the command line, started the setInterval and then observed the error and re-verifying the var is subsequently changing. I now take issue with the statement from post #2

'I guarantee this is not what's happening in JS'

as here are now three concrete examples.