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

'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__global_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/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

@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