Espruino JavaScript
On Pico WebIDE Connect - Unable to retrieve board information. Connection Error? #4744
Replies: 1 comment
-
|
Posted at 2018-08-16 by Robin An example where 'Sending' green progress bar doesn't always go far right and IDE hangs as can be seen from console output. Find attached the console output when I upload the following code snippet from: http://www.espruino.com/Individually+Addressable+LEDs I was unable to get the snippet 'random colours' to work, so I started a cut-n-paste of known working snippets in an attempt to understand that function. As the IDE hangs during upload, dis-connect is an only option. Then unable to reconnect with error as in #1 above. Attachments: Posted at 2018-08-17 by @gfwilliams Either the 'Native' or 'Chrome Web App' IDE should work fine for USB devices - it's just the IDE website that can't communicate with them. Baud rate doesn't matter for Espruino USB devices either. How are you powering the 25 neopixels? 25x 60mA is 1.5 Amps, which is more than the Pico's polyfuse will take - while uploading your code it turns on all the neopixels random amounts and it's pretty likely that it'll trip that fuse and the Pico will power down, which will mess up your upload. It's possible that could get the IDE into a bad state where it wasn't communicating properly, but I can't reproduce it here. Have you tried uploading some more simple code? There are some issues with the code you're uploading (like writing 25 times to all the neopixels during the upload process) - it shouldn't really cause problems, but it won't be helping matters... Posted at 2018-08-17 by Robin Fri 2018.08.17 Thank you for responding @gfwilliams. Although I hadn't indicated, it is amazing how we envision anothers project. For powering Neopixels, I knew the Pico only had a 3.3V 250mA regulated output, so that option was out. I also understood that a USB 2.0 port could only supply 500mA so might run the risk of blowing that up. Didn't want that risk, so during initial design finalization, I was able to locate a single SK6812 breakout board from DigiKey that I picked up eighteen months ago. 60mA Incidentally, I'm trying to locate that code file as it used the 'pre neopixel' module and worked fine then, to rule out the new module. > re: while uploading your code it turns on all the neopixels Why should the Neopixels be activated during the 'upload' process? In general why would code execute during a upload/copy process? > re: There are some issues with the code you're uploading (like writing > 25 times to all the neopixels during the upload process) Correction to link in #2 above the snippet 'random colours' is from example http://www.espruino.com/WS2811 Am I to understand that when using the upload button press process for right hand pane code blocks, that code is already executing before the upload is complete and before E.init is detected? If True, wont that make for erractic code execution since some lines would execute before the corresponding function definition has been loaded? Isn't that what the E.init entry point is for, making sure that nothing else executes before the init() function? I'll continue futzin with different combinations and other code files to see if I am able to uncover any other observations. Posted at 2018-08-17 by @allObjects
yes, read through the conversation about simple explanation how to save code that espruino run on start?. Posted at 2018-08-17 by @gfwilliams
http://www.espruino.com/Saving
That's not actually the code from http://www.espruino.com/WS2811 - you added the Normally what you might do is: Where the only command that's actually executed is
Yes - by default. Check out the
Yes, that's why you should put the code you want to execute at startup inside it rather than in the body of your code :) Posted at 2018-08-17 by @allObjects ...the issue is that the loop is in level 0... (JS to be executed immediately)... (the upload has already primed the module cache with the neopixel module - before the upload of the code (w/ the loop in level 0). Posted at 2018-08-17 by @allObjects
is not good enough on page espruino.com/Saving for people who do not come from a world of Espruino where code is executed on reception, or Browser (editing/modifying the dom while receiving dhtml), or 'writing' Smalltalk (editing the *life image), or Basic, or Python, or any other language when in the interpreter mode / context (not in the OS or command context)... just like the ZX80 / 81, ommodore Pet world, or any os (DOS) after invoking the basic interpreter... which did not have OSes, that was. Some more has to be explained there: ...uploading code means executing code on Espruino:
Entering the JS expressions in the left side is the same as uploading code on the right side - with one little but very significant difference: before (and while code is about to be sent), Opposite to the Browser where JS - all JS expressions - between the script tags are received and parsed as block before execution *** of the block, Espruino executes after reception of every complete JS expression that very expression. Posted at 2018-08-17 by Robin Fri 2018.08.17 It appears I have two or more simultaneous issues to resolve. The more difficult debugging task, rats! Point: As I have been unsuccessful at completing an upload, it would not be yet possible to learn that a line(s) of code are corrupting the upload process. An interesting Catch-22 Now that it has been made clear that code can execute before uploading is complete and possibly cause an IDE error, I'll start with that. Never occurred to me that upload could become corrupt from a static code file. [http://www.espruino.com/Saving](http://www.espruino.com/Saving) One can not learn of this precious factoid link as there is no entry point to that page: from: There is only one hyper link on an unrelated topic 'code is lost on power up' in FYI Typing in search the most obvious term 'uploading' returns no results Thought: When flashing new firmware, is the entire chip erased similarly to a format command, or are the contents of the Flash portion remain in tact, similarly to how the bootloader remains untouched? Posted at 2018-08-17 by @allObjects Flashing also erases uploaded code that has been saved (erase may not be the exact fact, but the pointers to the saved code are gone or the state that there is saved code is reset). Once saved code, there is always saved code... even uploading an empty editor (which is the method I use to remove saved code). The startup log entries are different: mentioning the execution of saved code is absent after flashing, and present after upload. May be there is another way to remove the information about saved code than (re)flashing (with same version). Posted at 2018-08-19 by Robin Sun 2018.08.19 Would someone that is able to flash an Espruino device without interrupting their current project be so kind as to provide a sanity check for me please. There appears to be some confusion from what appears to be opposing statements #10 @allObjects:
and
When I flash a Pico on a Win10 PC via the native IDE Settings >> Flasher >> Flash Firmware, every other Tuesday, when the wind is from the NW, skies partly cloudy, facing due East at precisely 07:01 pm CST, after a walk, but before having something to eat, disconnect, re-connect and http://www.espruino.com/Reference#l__global_dump My observations of present code contradict the two statements above. Could this garbled detail be from the IDE memory space and not the Pico? (no) This makes sense:
Did I mis-understand the point in #10 above, or should I do this on a Thursday instead? Posted at 2018-08-19 by Robin
Sun 2018.08.19 @allObjects I would like to learn more about 'level 0' as you indicate in #8 above: Presumeably there are other levels? I found an article, but no mention, so must not be clued in on the correct verabage to submit to a Google search. http://davidshariff.com/blog/what-is-the-execution-context-in-javascript/ Thank you in advance, Robin Posted at 2018-08-19 by Wilberforce Perhaps a better term would be global scope. The next level would be inside a function, so anything declared within a function is not accessible outside the scope of the function. Modules are an example of this. The only access to objects methods and variables are the items that get exported. Posted at 2018-08-20 by @allObjects @robin, sure. I'm in a time bind right now, but like to come back on the term 'level 0', or global scope/context - as @wilberforce - points out. Pls ping me when I do not followup. Posted at 2018-08-20 by @gfwilliams
It's there - a I'll add a keyword for 'upload/uploading'. I'm open to suggestions for extra places to link it, although there's a huge amount of information on the Espruino site, and it's a constant struggle to provide users with enough information to get started without overloading them to the point where 90% of them don't read anything. @allObjects I know what you mean about
Could you post up the code that appears? Your question about flashing to format all saved code is a little more involved than 'yes' on some devices, but on the Pico&WiFi it's not. If you reflash the Pico using the IDE and it completes successfully, it will erase all code. I can guarantee that. So if it isn't erased then either the flashing hasn't worked, or code got uploaded since you did the flashing. On Espruino 1v99 and later, just type
As @wilberforce says - global scope is probably a more general term here. I think JavaScript in a webpage is a good example here - If you write: On a webpage, that's going to make the webpage take a very long time to load enough to show If you upload: Then that's merely defining a function containing the code. The Posted at 2018-08-20 by Robin Mon 2018.08.20 @gfwilliams, there is still a bit of apparent confusion here. Although I have a better grasp on these issues, I feel that anyone new to this environment would have a heck of a time understanding what is going on. As did @allObjects also pointed out in #8. I only mention the following as it is likely that they might go down the same path.
Yes, agree totally. It is a very complex topic to handle all situations for each possible type of users development environment. No complaints
From #6 I originally asked:
The response was the http://www.espruino.com/Saving link. On that page,
So, as I read that, those concepts are on how to 'save' and use of the 'save'()' command. But the thought process is on the 'uploading' task. Incidentally adding will help
When the response from #6 was received, it didn't make sense to read on with the second sentence indicating to save code.
Even after reading the 'Saving' page, still haven't found what I need to know about the original question posed:
This is why @allObjects also agreed and posted his observations in #8 'Why' has been explained in #6 and #8 no need to re-hash. Posted at 2018-08-21 by Robin Mon 2018.08.20 Thank you to @allObjects and @gfwilliams in their responses above as their insight provided enough to resolve what is going on. I'm replying in several more manageble chunks to make review easier and as I'm not sure of the reply char count max. Observations: There were three separate simultaneous situations going on:
that occurs when uploading using the Right-hand text-editor pane, when:
causing the upload process to not complete, that then causes repeatable error:
As the IDE freezes, the only way to continue is to close the IDE and power down the connected device Recap: Eighteen months ago, I had a single SK6812 Neopixel demo working powered by a Pico using code fragments that are now superceeded by the 'neopixel' module. ref old Neopixel commands (circa Jan 2017) To assist another in a separate forum post, I fired up my Pico mounted on a breadboard. Unable to locate that older working code file, I copied the snippets and 'random colours' from the current Aug 2018 tutorial http://www.espruino.com/WS2811 As the pre 'neopixel' module code worked six months ago, my first incorrect conclusion was to blame the new module. The response from #7 set me straight that I was on the wrong solution path. I found the documentation superb and the authors need be recognized for their efforts. I only point out the following in the anticipation of helping others. Posted at 2018-08-21 by Robin Tue 2018.08.21 Situation 3 Error: 'Unable to retrieve board information. Connection Error?' The user is stuck in a Catch-22 at this point. As code 'Send to Espruino' never completes the upload process, one is unable to load the debugger, nor is one able to garner much more from the IDE console output. Without ample prior awareness and a load of actual usage, one may not have the insight as to what to do. The reason I started this post. It is not intuitive that a static code file can cause the IDE to freeze I agree with @allObjects in #8
for the intuitive reason I stated. As one is able to type commands directly in the Left-hand pane terminal window http://www.espruino.com/Quick+Start+Code and later learn that the same commands can also be typed in the Right-hand text editor, it never becomes obvious that a static ASCII file may cause issues as did this one I uncovered. Until you find . . . . Posted at 2018-08-21 by Robin Tue 2018.08.21 Situation 2 Syntactically correct Javascript lines of code, but poorly placed Reading the link provided by @allObjects in #5 above, then @gfwilliams #3 comment Have you tried uploading some more simple code? and after twenty plus upload restart cycles isolated the fact that code in a static file was in fact the culprit. I learned this before the balance of the responses, but those helped, as it validated what I was also seeing. A big plus. Actually taking a close inspection of the results of 'dump()' and after reading: From http://www.espruino.com/Saving Beneath 'Notes'
Here was the a solution to my issue that provided the insight as to what was going on:
In that process however, I noticed an IDE anomaly, that through sheer persistance was the root cause of not being able to make progress: Posted at 2018-08-21 by Robin Tue 2018.08.21 Situation 1 A repeatable project load native IDE anomaly Related issue but could be considered a unique new thread:
http://www.espruino.com/WS2811 I've discovered a near 100% repeatable anomaly with the IDE. Create code in Right-hand pane, upload to Pico, debug-upload, then when satisfied saved file to disk. Make edits to code in Right-hand pane, save then upload. If upload progress hangs and does not complete, disconnect and close the IDE. At this point your only option. Key point: Upload Hangs I actually commented out the offending Neopixel write and delay lines. But, . . . . Here is where the anomaly occurs. When the IDE is relaunched, the last code edits that were saved to disk do not get loaded into the Right-hand pane, leaving the corrupt code present that then also does not completely upload to the Pico. At this point, the anomaly is 100% repeatable. If not paying attention and miss that the old code is still there as it is beyond the 30 visible lines on IDE relaunch and then fail to manually reload the file that was saved to disk, one is stuck in the inability to get any code moved on to the Pico at all. This is partially what was causing my headaches, but I am now wiser to take the extra step and reload the code from disk EVERYTIME the IDE is restarted. Why doesn't the last saved file get loaded into the Right-hand pane on relaunch, . . . . Everytime? Incidentally, the saved edits do appear in the ASCII file save to disk Win10 edit file reveals this fact. Still need an explanation as to why the Pico Board Information appears to be recognized by the IDE Settings >> About, but when one attempts to connect, the error 'Unable to retrieve board information. Connection Error?' occurs. Why does the IDE understand the Pico data block but extracting that from the Pico is unsuccessful? Related to the apparent caching that occurs with the user saved code? Posted at 2018-08-21 by Robin Tue 2018.08.21 Summary The ol' saying: 'Experience is what you get, when you didn't get what you wanted' It's interesting to note that two missing slashes that weren't getting reloaded after a manual save could cause such fun! ;-) It never becomes apparent that the last saved file is not getting reloaded, when code edits are beyond visible line 30 during app launch. It is as if a cached file image is never updated, and on relaunch that the pre-save image is used rather than the actual file content that is on disk. This actuality is what blocked me from making progress. You never see a visible change in the Right-hand pane on relaunch so most likely would never think to look lower down, further into the file to see if the changes took place. Why should one, when a save was last initiated? One expects save, well to actually save and re-launch to actually load our previously saved code. I also had to hold down the reset button and plug the Pico in to erase, before I could successfully upload. Once at least one valid code block did upload, I was able to continue edits and upload went fine from then on. An individual new to this environment most likely would never know what to do at this point either. I hope these last three Situation posts and this Summary will assist others, should they have the same error. Thanks again @gfwilliams and @allObjects for the insight in providing enough to get me up and running. This was one heck of use of time, but did provide a wealth of Experience. . . . Posted at 2018-08-21 by @allObjects As @robin AND @gfwilliams point out regarding my self doubt about a better way to clear saved code then re-flashing [see post #10] by using Attachments: Posted at 2018-08-22 by @gfwilliams
It's a restriction of the Chrome Web App unfortunately - it's very hard do do anything when the app closes - so you either have to save every change (in which case Google has a limit to the number of saves to cloud storage) , or every upload - which is what I have been doing. The new IDE code should help with this, but that's not live for Native IDE and Chrome Web App user yet. Could you upload the exact code file that gave you the upload error please? Then at least i can try and figure out why it is breaking. Posted at 2018-08-22 by Robin Wed 2018.08.22
Are we on the same page here? I included the .js file in #2
I made the assumption that your @gfwilliams responses were based on viewing that code file. If the inquiry was referencing the two slashes I mentioned, that is in front of the code line 'delay()' immediately following the 'write()' line inside 'random colours' My findings and summary documentation were immediately completed after that observation. Haven't even had time to get back to my original goal of writing code yet. Spent the first five days attempting to find a way to get a reliable stable environment. Please see this from my point of view, the IDE always locked then crashed, so had no way to access any of it's functionality. Ref #19 Posted at 2018-08-22 by @gfwilliams Ok, sorry - I forgot that. Yes, the responses were - and I remember trying and it uploading fine - but I'll try again on windows and see when I'm back next week. It'd be interesting to see if everything uploads fine with the LEDs disconnected? Posted at 2018-08-22 by Robin Wed 2018.08.22 Actually, the Pico is just plugged into the end of a USB cable. Testing was performed not connected to anything. Posted at 2018-08-23 by @allObjects Updated post #10 about erasing saved code with a screenshot. Replugging the Pico after erasing saved code and unplugging showed that code was gone: no blinking of the previously saved 'blink' code. Posted at 2018-08-23 by @gfwilliams I have to say I'm really struggling here - I'd say the delay on upload is a bit of a red herring. Something else is definitely happening in your case. Running your code exactly as you gave it to me on a Pico with 1v99 and nothing plugged in works perfectly on Windows Native, Windows Chrome App, and Linux Chrome App. No crashes, no reconnect problems, nothing. Posted at 2018-08-23 by Robin Thr 2018.08.23 I was trying to uncover a line of code that shows up during a dump() after power on. Thought it might provide a bit of a clue.
Something like B15 opendrain Nothing I wrote or in the file that is uploaded. Went to perform a sanity check, but now get the following error: 'Module neopixel not found' I thought all modules using 'require' were found at http://www.espruino.com/modules/ Console listing validates:
Attachments: Posted at 2018-08-23 by @gfwilliams
The hardware-specific ones (like neopixel) are of often built in to Espruino - you can usually see them in http://www.espruino.com/Reference That error will occur if you've previously had the 'unable to retrieve board info' error - because the IDE hasn't been able to communicate with the board, it hasn't been able to find out what modules are built-in, so it looks online anyway just in case. Posted at 2018-08-23 by @gfwilliams I notice in this one it's connecting to COM3 and getting no answer, when previously it was COM4. Do you have different boards that you're using? It could be possible that you're just connecting to a COM port belonging to a different bit of hardware (it's happened before!). Also, is there any chance that another application is trying to use the COM port at the same time? I think you're using the Chrome Web App rather than the Native IDE? But if you use the Native IDE does it work any better? It's worth a try I guess! Posted at 2018-08-23 by Robin
Okay, thanks got it > 'Something like B15 opendrain' Was really hoping you might have a clue as to what command might be causing the code related to B15 and if that could be the culprit > 'Do you have different boards that you're using?' No, just the one. Same cable connected to same USB port. Could re-flashing have any cause-effect on what Com port is recognized then? EDIT Thr 2018.08.23
I noticed that too, but was the only option this time launching the native app. Have always been using native app since Chrome can't connect to Puck. I have also noticed that on this HP laptop, the native app sometimes sees one or both Com3 or Com4 Ahhh, . . . . Here might be a big clue. After re-reading your response, I tried again, but this time pressed the reset button after applying power to allow boot with clear memory. In that mode Com3 is recognized. When just applying power to the Pico, it's Com4 Now the big question: Why?
Not intentionally. Same cable, same USB port. Aren't COM ports dynamically assigned as needed? EDIT Fifteen minutes later. . . . From #15 your comments
To re-iterate. I've never typed 'save()' Was done over six months ago though. The puzzling part. The Pico was at ?1v96? when I left it six months ago. In frustration, before starting this thread, when I couldn't connect, I realized I had re-installed ?v66? then, the native app, now v68.6 as I was unable to connect to a Puck six months ago. So, on a hunch, I flashed the Pico which was successful, other wise the Espruino banner and 1v99 would not have been seen. see post #1 including console output My contention is that all of memory is not getting erased during a flash, otherwise there wouldn't be the Com3 vs Com4 using reset button on power up. Correct? but, now I can't connect, . . . again. ref
EDIT Seven hours later . . . . Finally got the Pico to connect and the 1v99 banner (see #1) is present and find attached a dump() of what is stuck in memory. It is the contents of a small program, in a different order than coded, that I was working on, but never completed six months ago. What is visibly missing this time is what was appearing as the last line of code, something like After doing a lookup in reference section, the only argument that appears to be what I remember is: af_opendrain or opendrain Have no clue how or why that line was appearing, as it isn't in the source file. *So, . . . somehow, this Pico never erased memory during a flash to 1v99 using the native IDE* This also coincides with a user this week having near similar issues, but with a Puck
http://forum.espruino.com/comments/14382852/ Similar situation not being able to connect, then had to downgrade first, before successful (re)flash Just guessing here: Is there a way that the flash process never completes, but is able to produce the 1v99 and Espruino banner? Leaving chunks of the previous flash intact - layered somehow? Is there a checksum or something similar that may be learned from console output in #1 @gfwilliams, is there anything you would like me to try before I attempt a downgrade? EDIT Fifteen minutes later Finally the line appears!! This dump() attempt produced the last line as pinMode(B15, "af_output", true);
My file only references *require('neopixel').write*
Is that module adding the above line and somehow that is corrupting memory?
Attachments: Posted at 2018-08-24 by @gfwilliams The B15 code really shouldn't make much difference. The fact that it's still there is very odd though. Is it possible that the red and green LEDs were glowing on and off when you had trouble connecting? It could be that you had the board in bootloader mode - that might explain why there were two different COM ports (although it might also depend on the Espruino version). Now you have it working, if you type 'process.env' what does it say? Posted at 2018-08-24 by @gfwilliams Just to add to this... If others hit this issue, what did you actually do to get it working?
On the Pico if you had a very early version of the firmware before it is possible.
For new hardware. If you have the port open in another application then the application will 'claim' that port and usually it'll be unusable by any other application until you disconnect the first one.
As I said before - on the Pico, if the flash has been successful, all flash will be erased. I'm certain of that. Saved code sits halfway between two bit of Espruino firmware, and so to update the whole firmware the saved code must be erased, On top of that, in versions 1v96 and later there's extra code that actually checks the version of the firmware so even if you had saved code from another version it won't be loaded. If you're getting that code shown from Is it possible that you actually have two Picos that are getting confused? That might explain some of these issues with stored code that you don't believe you uploaded. Posted at 2018-08-24 by Robin Fri 2018.08.24
The same detail is returned that was spotted in #1 from the IDE Settings >> About >> Board Infromation
Posted at 2019-02-20 by itpdm Unable to retrieve board information. Connection Error? Attachments: Posted at 2019-02-20 by itpdm 但是我用串口助手是可以回去板子信息的 哪位前辈可以帮帮我 Attachments: Posted at 2019-02-20 by itpdm 这是我下载的固件 Attachments: Posted at 2019-02-20 by itpdm 这是我的操作步骤 Attachments: Posted at 2019-02-20 by itpdm 设置了波特率 115200 Attachments: Posted at 2019-02-20 by itpdm 选择串口 点击com5后提示错误 Attachments: Posted at 2019-02-20 by @gfwilliams Please can you post in the ESP8266 version of the forum? http://forum.espruino.com/microcosms/925/ You're more likely to get help there as this is definitely ESP8266 related. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-08-16 by Robin
Thr 2018.08.16
Well this one baffles me.
I wanted to play with a Pico that hadn't been powered up in over six months. The code file was still in tact and the breadboard still wired. Using USB cable for power. Launch IDE. Plug in Pico via cable, onboard red LED flashes once and Windows10 connection sound bite becomes audible. Click ORG connect button 'Select a Port' dialog renders. Click - 'Connecting' then immediate 'Connected to port COM4' followed by 'Unable to retrieve board information. Connection Error?'
then 'Disconnected'
After many connection - relaunch attempts;
Didn't want to add another layer of confusion, but wondered if the firmware was toast. So in frustration, went through the IDE firmware flash process, which in fact was successful and now have 1V99 and familiar 'Espruino' banner renders on left pane.
Was able to run several left pane instructions and loaded a few code snippets in right hand pane. Success! Took a break.
Upon returning, Pico had disconnected and ORG connect button was rendered. Greeted with 'No Ports Found' Ol' familiar Window10 routine.
Close IDE. Power down Pico. Relaunch IDE. Power Pico. Attempt connect. Now the Error.
I had been playing with a Puck recently, and now unable to recall if I re-installed the IDE as I was one that was confused as to which IDE was specific for the Puck. Now I understand it is the native IDE. That is now at:
Web IDE version 0.68.6
Baud 9600 tried at 115200
Here is the IDE console output, full content attached:
I cleaned the Pico contacts with a pink Pearl eraser. I added more tension to the USB holding tabs. I am successful at flashing the Pico. So connectivity doesn't appear to be an issue. Kept Baud rate at 9600, but not sure if that would have an impact.
At times, during a code upload, the 'Sending' green progress bar doesn't always go far right, so I'm never sure if the code actually uploaded.
Baffled that I am able to at least once, connect and flash, write some code, then poof - start cycle over.
From Settings >> About
Ideas anyone? Thanks in advance. . . .
Attachments:
Beta Was this translation helpful? Give feedback.
All reactions