On Pico WebIDE Connect - Unable to retrieve board information. Connection Error?

Wed 2018.08.22

Actually, the Pico is just plugged into the end of a USB cable. Testing was performed not connected to anything.

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.

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.

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.

Incidentally have never typed 'save()' during uncovering this, since
the Pico has been connected. Made sure of this fact the moment I
started this post Thr 2018.08.16 and extremely careful not to corrupt
the debug process.

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'
and, . . . cursor does not resort to the '>' prompt

I thought all modules using 'require' were found at

http://www.espruino.com/modules/

Console listing validates:

loadModule(neopixel)
Espruino.Core.Utils.getURL: got HTTP status code
404 for http://www.espruino.com/modules/neopixel­.min.js
Espruino.Core.Utils.getURL: got HTTP status code 404 for
http://www.espruino.com/modules/neopixel­.js
WARNING: [notify_warn] > Module neopixel not found

---

1 Attachment

• 

I thought all modules using 'require' were found at ...

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.

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!

'I thought all modules using 'require' were found at ...'

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

Com3 vs Com4

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?

re: 'is there any chance that another application is trying to use the COM port at the same time?'

Not intentionally. Same cable, same USB port. Aren't COM ports dynamically assigned as needed?

EDIT
Fifteen minutes later. . . .

From #15 your comments

'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.'

To re-iterate. I've never typed 'save()' Was done over six months ago though.
and flashing did work 1V99

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
http://www.espruino.com/Troubleshooting

'. . . and Espruino loads it at power on and breaks itself each time. To stop this:'

On Espruino Pico/WiFi
Unplug the board from USB
Plug the board in and immediately press the button (but not before you've plugged the board in)
Wait 2 seconds
Release the button

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 pinMode(B15, opendrain

After doing a lookup in reference section, the only argument that appears to be what I remember is: af_opendrain or opendrain
http://www.espruino.com/Reference#t_l__g­lobal_pinMode

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

'Cannot connect to Puck.js after updating Firmware to v1.99 with Windows 10'

http://forum.espruino.com/comments/14382­852/

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

@Gordon, is there anything you would like me to try before I attempt a downgrade?
Which .bin file would you recommend to try first?

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?

---

1 Attachment

• CodeDumpAfterFlash20180823.txt

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?

Just to add to this...

If others hit this issue, what did you actually do to get it working?

Could re-flashing have any cause-effect on what Com port is recognized then?

On the Pico if you had a very early version of the firmware before it is possible.

Aren't COM ports dynamically assigned as needed?

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.

My contention is that all of memory is not getting erased during a flash

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 dump() then you must have uploaded and saved that code to it at some point since the firmware update.

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.

Fri 2018.08.24

re: ' if you type 'process.env' what does it say?'

The same detail is returned that was spotted in #1 from the IDE Settings >> About >> Board Infromation

process.env
={
"VERSION": "1v99",
"GIT_COMMIT": "f0d66ba",
"BOARD": "PICO_R1_3",
"FLASH": 393216, "RAM": 98304,
"SERIAL": "25005800-13513335-32373134",
"CONSOLE": "USB",
"MODULES": "Flash,Storage,fs," ... "b,crypto,neopixel",
"EXPTR": 536871156 }

Unable to retrieve board information. Connection Error?

---

1 Attachment

• 

但是我用串口助手是可以回去板子信息的 哪位前辈可以帮帮我

---

1 Attachment

• 

这是我下载的固件

---

1 Attachment

• 

这是我的操作步骤

---

1 Attachment

• 

设置了波特率 115200

---

1 Attachment

• 

选择串口 点击com5后提示错误

---

1 Attachment

• 

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.