• 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 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

About

Avatar for Robin @Robin started