Most recent activity
-
Sun 2020.03.29
two hours later
This time a possible parsing issue.
I stripped out more comments, now making 800+ JSVARS available. I put back in a function that just prints to the console, but on startup am now faced with a 'FIFO_FULL' error. I commented out that L1248 df() function call, and a new error popped up, but that made sense, as I had stripped the setWatch and inlineC section from Test3, under the assumption that maybe there was a parsing issue with the 'C' code. See Test4
New interpreter error: FIFO_FULL >dmf() [ "FIFO_FULL", "LOW_MEMORY" ] =undefined >pm() { "free": 838, "usage": 1662, "total": 2500, "history": 728,
So, I inserted the setWatch and inlineC back in. L225 thru L 244 in Test4aNow the error is cleared. Note that this pushes the entire balance of the file downward, by around twenty lines, as the file now has more code lines. On upload, the error in post #8 is now gone!
Performing a dump also confirms this. L996 dump20200329a1109Test4aFORUM.txt
This now points to a parsing issue.
-
Sun 2020.03.29
I have run into a bizarre troubleshooting situation, that has been narrowed down to a parsing issue, or
a potential corrupt memory situation.See: Technique needed to notify of low memory condition during runtime
Under the assumption this is not a parsing issue, maybe a hardware one.
Is there an exhaustive test to exercise RAM to inspect for flaky cells?
I realize this gets a bit tough as Espruino will need to run, and the test program will be part of that memory. But, maybe some detail may be garnered from testing the balance of memory perhaps?
-
Sun 2020.03.29
Fresh start. Power on MDBT42Q. Start WebIDE. Same code file where I left off.
This is starting to appear to be a parsing issue, or when data chunks are sent to the MDBT42Q, they are not being received as they were sent. Now a new error appears:
Uncaught SyntaxError: Got UNFINISHED STRING expected EOF at line 934 col 27 console.log( " " ); " );dump() shows that line L7 is there, fifth inside the help() function:
function h() {help();} function help() { console.log( " " ); console.log( " " ); console.log( "Tutorial PPI - Programmable Peripheral Interconnect" ); console.log( " for the MDBT42Q Breakout board" ); console.log( " " ); " ); console.log( "Single letter command line helper functions" ); console.log( " " ); console.log( " " ); console.log( " h() help " );
If one inspects around L730 in the source file, it can be seen the correct syntax is present. The dump is showing that [console.log( "] is missing L8 from what was originally there.function h() { help(); } function help() { console.log( " " ); console.log( " " ); console.log( "Tutorial PPI - Programmable Peripheral Interconnect" ); console.log( " for the MDBT42Q Breakout board" ); console.log( " " ); console.log( " " ); console.log( "Single letter command line helper functions" ); console.log( " " );When I attempt to view the console output:
WebIDE :: Settings >> Console
BT> Sending "\n// External button " BT> Sending "press sends one puls" BT> Sending "e\u001b\nswbp();\u001b\n\u001b\n\u001b\n\u001b\n\u001b\n" BT> Sending " // Sync flag with " BT> Sending "pin state\u001b\n dp();\u001b\n" BT> Sending " sync();\u001b\n \u001b\n}\n\u0010\u001b["
I note that data is sent by the WebIDE in small chunks. Presumeably the device sends back similar manageable small chunks in response to the dump() request. I've tried to capture the outbound file, but just not quick enough to open the console output, before it is pushed off the top.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.
-
Sun 2020.03.29
The following is 100% reproduceable, just uploading the code.
Uncaught ReferenceError: "dpu" is not definedI performed the following three times as I couldn't believe my luck finding a repeatable condition.
Out of all the situations I've come across this past week, this is the easiest to reproduce.I've gutted nearly 1/2 of code file lines, primarily external comment blocks, embedded comment lines within functions, and any code snippets that weren't needed to run a simple test.
It shouldn't be necessary to wire external pins as code no longer functions, although I haven't tested.
To get to this final file, the goal of the project no longer works, and many features can no longer be tested. That's okay at this point, as I've found a 100% reporoduceable situation. It appears that whatever table mechanism that references internal functions by name, becomes corrupt and therefore unaccessible, just by uploading!
3x I've powered off/on the device. I've closed/opened the WebIDE. I haven't rebooted Windows10 yet, but will do soon as I also search for, and try other lint tools.
I added some simple function wrappers to avoid having to type long commands.
Display Memory Flags Error >dmf() Process Memory shortcut >pm() Run Garbage Collection >rgc()I load the code file from disk. I upload to the MDBT42Q.
It takes twenty seconds to settle down before the second > prompt is visible.
At this point, an attempt to run function dpu() results in:
Uncaught ReferenceError: "dpu" is not defined at line 1265 col 3 dpu();Typing dump() or searching within the WebIDE editor will find that function at L200
I've run every combination of the following, and ther results are approximately the same. Running a garbage collection does clear the 'LOW_MEMORY' flag and frees up 6 JSVARS. Repeatable.
Here is a sample:
Even with 30%+ free JSVARS, no MEMORY error, but a hidden LOW_MEMORY flag is set:
>dmf() [ "LOW_MEMORY" ] =undefined >pm() { "free": 816, "usage": 1684, "total": 2500, "history": 732, "gc": 0, "gctime": 4.0283203125, "stackEndAddress": 536928592, "flash_start": 0, "flash_binary_end": 428148, "flash_code_start": 442368, "flash_length": 524288 } =undefined >rgc() [ ] { "free": 811, "usage": 1689, "total": 2500, "history": 734, "gc": 0, "gctime": 4.11987304687, "stackEndAddress": 536928592, "flash_start": 0, "flash_binary_end": 428148, "flash_code_start": 442368, "flash_length": 524288 } =undefined >dmf() [ ] =undefined >pm() { "free": 816, "usage": 1684, "total": 2500, "history": 736, "gc": 0, "gctime": 4.0283203125, "stackEndAddress": 536928592, "flash_start": 0, "flash_binary_end": 428148, "flash_code_start": 442368, "flash_length": 524288 } =undefinedAttempting to run a function that is visible on the code side and within a dump() results in:
>dpu() Uncaught ReferenceError: "dpu" is not defined at line 1 col 1 dpu() ^ >r() counter: 0 counterPulses: 0 Uncaught ReferenceError: "dpu" is not defined at line 1265 col 3 dpu()Performing a dump() will clearly show the function listed in tact L367 around the first quarter of the dump, as everything does not match the source file chronological order.
I'm posting this here now, as this ran a week ago before I started adding more comments and additional accessor functions. I'll search for other lint checkers, and continue testing tomorrow with a fresh start.
Windows 10, version 1909 64bit Web IDE version 0.70.6 { "VERSION": "2v03", "GIT_COMMIT": "e77d74f6", "BOARD": "MDBT42Q",Butchered code file to get the repeatable error, so withold the comments on format and style. ;-)
L367 in dump20200328p0807dpuTEST3.txt file is the dump showing function exists
-
Sat 2020.03.28
post #2 'However, if you have problems even without that and you HAVEN'T seen any MEMORY error on the console, it's not an error to do with memory getting used up'
If I understand the above, I don't appear to have problems as nothing was being displayed, and I 'hadn't' seen a
MEMORYerror while reducing the file size, but I do now see aNew interpreter error: FIFO_FULLerror, so not sure if that is inclusive for the above statement.Okay, worked all day on this. While I have been extra careful over the last two years to make sure all code is inside separate functions so no execution occurs during upload, I've double checked and verified this is the case, along with making sure nothing other than several vars are initialized, only a function call to display a shortcut list of function call names is rendered. I ripped out many tens of lines of code to get the file size waaay down, so that there were around 600-700 JSVARS available, so as not to run into the ~100 JSVAR minimum that I have read elsewhere that must not be exceeded.
I issue a
reset(1)within the WebIDE. I clear the console, button upper left. Even with now a much smaller code file, now when I just upload that file, a new error appears, but not theMEMORYerror mention in the response above.I even unplugged the MDBT42Q, in case something corrupt remained, but is consistent, despite nothing I am intentionally doing would be causing a 'FIFO_FULL' error:
New interpreter error: FIFO_FULL >This error is consitent with what I witnessed yesterday, post #3 with the significantly larger file but during runtime. So, maybe that 'FIFO_FULL' flag has always been there, as I wasn't aware to even detect that until the suggestion in post #2. What is really puzzling is the now 'LOW_MEMORY' flag, despite only using 70% of memory. This actually ran several days ago with only ~200 JSVARS remaining, so with an additional 400 free now, shouldn't be an issue.
I upload the code file from the Right-hand editor side, and the following is observed, and entering the command, flags can be seen that are set:
New interpreter error: FIFO_FULL > >E.getErrorFlags() [ "FIFO_FULL", "LOW_MEMORY" ] =undefined >While creating the content for this post, I entered
dump()and re-ran a memory check, and now the flags are reset!{ "free": 667, "usage": 1833, "total": 2500, "history": 602, "gc": 0, "gctime": 3.90625, "stackEndAddress": 536928592, "flash_start": 0, "flash_binary_end": 428148, "flash_code_start": 442368, "flash_length": 524288 } =undefined >E.getErrorFlags() [ ] =undefined >
The new question, what is causing theFIFO_FULLerror when just uploading code? I'm not seeing theMEMORYerror and there are 600+ JSVARS available, so there shouldn't be a memory issue, correct?http://www.espruino.com/Reference#l_E_getErrorFlags
'FIFO_FULL': The receive FIFO filled up and data was lost. This could be state transitions for setWatch, or received characters.
'LOW_MEMORY': Memory is running low - Espruino had to run a garbage collection pass or remove some of the command history
'MEMORY': Espruino ran out of memory and was unable to allocate some data that it needed.What is the trip point for low memory as I've stripped 30%+ and still get the flag on upload:
{ "free": 871, "usage": 1629, "total": 2500, "history": 726,Note that running a forced garbage collection
process.memorydoes clear the flag. -
Sat 2020.03.26
'please share build version and a code snippet'
Build version is provided at the end of post #1 code file at post #12 link here
Thank you @MaBe for taking the time to read through this post, and your enthusiasm and curiosity to assist here.
I purposely wrote the content and selected the title requesting a 'Technique' as I realized debugging this will be too time consuming to put anyone through. I also realized Gordon would understand that, as he had been assisting here in another thread I started a month ago, and wouldn't be available, (see post #9 there, below) until after the Bangle K.S. shipments. I kept the request terse, knowing that I could move forward with a simple technique as reducing the demand on memory, may and most likely allow me to see this through to completion.
post #12 Tutorial example output anomaly using low level access PPI on MDBT42Q breakout board
To 'whet your whistle' I discovered some cool stuff using PPI that would make for a great multi-part tutorial to put the Javascript haters at bay, demonstrating near one-for-one match with that other 'C' programmed ubiquitous device.
The last code file in post #12 above worked as I described above in post #1 here, great until I started adding functions that called multiple console.log statements rendering var contents to the WebIDE console. I knew I was running short on memory in the other thread, and continuing was going to be a challenge.
I've also toyed with whether I'd be better off attempting to teach others to use this tutorial in order to find a solution, compared with just pluggin' along knowing it's likely a memory issue. My realization is that I would spend more time attempting to convey concepts and use others time that will be needed with Bangle, than just continuing performing tests with Gordon's new suggestion. The code file is over 1500 lines of code and comments, and is using 90%+ of available memory.
To move forward, the six bulleted items at the end of post #12 need more needed attention at the moment, in order for me to complete this tutorial. Adding Gordon's suggestion, and seeking solutions to pare down the existing file size is trivial at this point. Providing assistance in solving those items would be a more prudent use of your time, should you be able to spare it, and thank you.
Should I not find a suitable solution within a week, I'll post the entire code file as it sits.
-
Fri 2020.03.27
Thank you @Gordon for the reply.
'I guarantee this is not what's happening in JS'
I can assure you that after running a setInterval that updated once a second, calling a log to console method, printing the contents of around twenty vars, worked for at least five minutes, then multiple errors such as the one in post #1 indicating 'undefined' started popping up. I attempted to print those vars from the command line Left-hand console side, same error.
Doing a dump, and the defined var that is clearly seen on the Right-hand editor side, and the var is clearly there, that was uploaded. Doing a search both in the source using Notepad++ and within the WebIDE editor match. But now attempting to run a wrapper function that calls the console.log statements now won't even run, also providing the same error. So Espruino is informing us that it can't find the previously declared var either, otherwise it would just return =undefined when not assigned a value.
I even performed a sanity check on the L.H. console side to see what error is seen when an attempt to view a known non declared var is entered and the same errror occurs.
I never defined rrr so this is correct - and the same for the now missing var
>rrr Uncaught ReferenceError: "rrr" is not defined at line 1 col 1 rrr >intervalID =undefined
I scrolled through the dump contents and the var that is defined in the code that was uploaded is no longer there.I'll copy the contents of the console to a text file and take a fresh look at both the dump and the output, along with running more tests tomorrow. I'm chicken to power down/try again, in fear of not being able to have this repeatable situation, be reproduceable.
If your statement above is accurate, what other ideas might make a var disappear?
I'll read over the errorFlag event tonight and play with it tomorrow. Maybe that will shed some light.EDIT: This is what is shown just after the undefined errors start to occur:
>E.getErrorFlags() =[ "FIFO_FULL", "LOW_MEMORY" ] >
The LOW_MEMORY is obvious, and the FIFO_FULL most likely occurs as the logging function throws the error, bypassing or delaying the ability to turn off a pulse train created by analogWrite and the corresponding setWatch fills quickly.
Sun 2020.03.29
Hi @user110828 Neil, is the inquiry on how to extend one of the returned objects in order to add a new user defined modifier key?
Example
Reference