Pico's ESP8266 weirdnesses (Module not found)

Posted on
  • Hello again,

    I spent some months with other things and I am now trying my new "ugly" Picos (from the Tindie sale). Blinking the LED does still work as expected, but WiFi.. also still has issues.

    Even after updating to 1.79 and trying both binaries...

    (BTW:Why do I have to choose between Wiznet and CC3000 binaries, if I actually want to use that cheap 8266 with my Picos?)

    ... I get an Module not found for the "ESP8266WiFi" and missing functions for "ESP8266" (which is how it's referred to inside the module code). Something I am missing? Is there a way to display the available modules (not the cached ones, but the built-ins)?

    I hope it's some stupid mistake on my side and someone can show me where my weekend enthusiasm went wrong.

    Cheers
    Stev

  • Did you upload using the web ide? And if so did you use the right hand side and click the upload button?

    The web ide automatically downloads modules, but only for code in the right hand side pane, as the left hand side communicates directly with the board. Available modules are at espruino.com/modules

    The esp8266 one doesn't come built in, but the cc3000 and wiznet do - why you have to choose when flashing. I could provide firmware without them, but it doesn't really help in any way.

  • Hey,

    Thanks. That's will be the reason. Should have just done the blinking LEDs for my first day back.

    I usually used Espruino via the command line. Of course I had the modules on SD card on the "classic" one.

    Will try again tomorrow using Module.addCached() or even use the IDE.

    Will you be able to provide a binary with the Modules needed for the ESP8266? Would be great at least for my typical workflow, as pasting code on the Pico seems to fail more often than on the classic Espruino. Don't know if the CLI buffer is smaller or something? Also having the Wiznet or CC3000 flashed does not help anything with 8266. Don't know how many people run both.

    Thanks again, will talk back, once it runs.

  • BTW: pretty nice new HW. Thanks for keeping at it that much.

  • Ok, now I am having problems with talking to the ESP8266 via serial, it seems.
    I get the "no 'ready'" error and I am seemingly not able to talk to the chip via Serial.

    For the capacitor, does it make a difference, where you add it and how long the cables are (breadboarding right now)?

    Also, I am not sure about the Wifi-Enable pin. When I don't draw it to 3.3V I see a blink of the blue LED on the ESP8266 for serial activity, if I pull it up, I don't.

    The funny thing of course is that I cannot ask the chip for its version without having it talking via serial...

  • Works now, with a CIPSTART failed now and then.
    But to return at least something to the forum I can report that the ESP8266-01 shipping from Watterott last week have the 0018000902-AI03 firmware and report a[Vendor:http://www.ai-thinker.com Version:0.9.2.4] on start-up.

  • Are you using espruino-tools to upload to the Espruino, or something else? That'll automatically handle modules in the same way the Web IDE does.

    I'm re-writing the USB comms as part of the USB HID stuff - the F4's USB code does seem to have some issues, and I think node.js pushes USB data out in larger blocks, which makes it more likely that there will be problems. Hopefully in a few weeks the next firmware update will have totally solid USB comms.

    I'm not planning on a version with ESP8266 built in though - it's enough of a pain producing all the firmware builds I do right now, and I don't want to make more work for myself :)

    I do want to make sure there's a good, reliable, easy to use command-line tool though - and hopefully that will solve the majority of your problems.

    Works now, with a CIPSTART failed now and then.

    What did you change to get it to work? Was it wiring?

    A blue flash at startup is good - it shows the ESP8266 has booted into the firmware and has output some information.

  • I used to just use screen on my mac, which now seemed even more tempting since i don't need a cable anymore. "Just talk to the chip", basically, seems really cool to me.

    So far (a year ago) I just pasted the minified js code and saved it. Using addCached for the Modules. Worked fine. Saving is an
    awesome feature, too.

    However on the original Espruino pasting worked fine with flow control/buffering for me. The new one stops somewhere in the middle when pasting larger code pieces

    since it's going via serial lines: Do we have/can we expect to have a functionality to send. Checksummed code, maybe in chunks, and join them on the board again? Or is there already something that works with the Web IDE that can be re-used? While it mostly worked fine there was always that bad feeling that something could have been changed during transfer. I could use echo to check each input, but that seems a bit to much feedback.

    For the current problem, I have no idea. I ripped everything apart and talked to both sides vie USB-UART. Then reassembled. Then it worked. Bad wiring/breadboard, can't really say.

    Something bordering on esotericism was to draw RST explicitely to Vcc. Of course it worked without that as well afterwards. So... At least the bug was expelled.

  • The new one stops somewhere in the middle when pasting larger code pieces

    Yes, hopefully that'll be fixed soon with the new USB changes - I'm still fighting trying to reliably fix that exact same problem. On the Web IDE it should work though because it delays a bit more than screen does.

    can we expect to have a functionality to send Checksummed code

    I guess it's possible - it'd have to be some strange extension to the console.

    However it shouldn't be needed. My understanding is that USB already has checksumming built in, so you know the data you get is valid and arrived. The fact that data is getting lost is a bug in the USB code, which needs to be fixed.

  • Ah, ok. I also had some strange effects when using the left side of the WebIDE and in the end had some kind of "pure serial line in the middle" on my mind after those issues with the 8266. Since the connection to the Pico is USB you should be right about the checksumming and the missing return channel/echo chars on the WebIDE are probably due to the same bug.

    I guess I was also a bit burned by the transmission problems with the HY-MINISTM32V 3.2 I had last year and now when trying to flash the pico via the CLI instead of using the WebIDE (always resulted in several false values during verify) and didn't think about the actual connection type.

  • trying to flash the pico via the CLI instead of using the WebIDE (always resulted in several false values during verify)

    Did you add the -k switch? http://www.espruino.com/Serial+Bootloade­r

    You'd need the stm32loader.py from the Espruino GitHub repo. Basically the F1 chip doesn't have a USB bootloader, so I made one that emulated its' Serial bootloader - however an errata on the STM32F1 chip meant that USB was unreliable unless you changed a few registers first (which that -k flag does). The Web IDE does it automatically...

  • I think so. I used the line from the Download page, which has a -k in it. If you didn't add that just today...

    Back then I had huge problems with flashing the Hi-Mini from OS X until I wrote some code to control the timing/delays better and shorten the binary chunks. Maybe the IDE also uses some delays that help here? I tried flashing the Pico three times using the Python script (which all failed on verify) and then had the WebIDE succeed on first try. Unless it just ignores the result of the verification step :)

  • @Stev ahh - yes, that's your problem. The USB bootloader is also in flash, and to make sure you can't easily brick your Espruino, it won't overwrite itself.

    That means that if you write an image to Espruino using the USB bootloader, the first 10kB (on Espruino) or 16kB (on Pico) probably won't be right. If you check the results of the verify you're fine if everything above there matches.

  • Ok. Seem's I ran into every re-noob issues that were available...

    However, at the moment, I'm totally frustrated by the USB-Console breaking even in the WebIDE and comms to the ESP8266 working once, failing twice (that's just a metaphor, I'm afraid), despite delays and what not. Usually I don't reach the point where I could debug the actual app protocol since something already failed on the way to the AP connect. Now an then it works, but I will not be able to change and test something on the app's HTTP protocol level since I won't have a working connect for a long time and meanwhile I have to disconnect and reconnect the Pico's serial to get the output in the WebIDE. Don't know if it's me or the chip, but's costing hours right now.

    I guess I will wait a few weeks and see how that evolves. Right now I wonder, if there's something generally broken with the serial comms, Console switching or something, not only on the USB side.

    Maybe, I'll try with the original Espruino and the voltage regulator in the meantime. Will see...

  • Hmm - worth a try to see if the original Espruino is any better (or even just adding an external voltage regulator) - it could be that it's caused by some bad connections though - the fact that it's unreliable rather than flat out broken makes me think it may not just be software.

    Also... having to unplug/replug Espruino to get a response? It sounds pretty strange on the latest firmwares - if you can come up with a simple example bit of code that breaks it then I'd be happy to take a look.

    Are you still breadboarding? If you're not using the shim, the voltage drop/bad connection over the wires is enough to totally throw off the ESP8266 module. Soldering a decent size capacitor right to it might help, as would making sure the wires between it and the Pico are as short as possible.

  • Yes, soldering will be today's try to solve the issues. The fact that it sometimes worked and sometimes not at least points to doing so.

    I have a 100uF capacitor somewhere in between which also should get a better position that way, as one of my ESP boards even managed to reset the Pico on Wifi connect. What is the typical capacity that should work with direct wiring? The shims are not yet available directly/from stock somewhere, are they?

    For the console output, I have to connect/disconnect via the WebIDE's top left button (or re-connect screen) to get the output.

    Also, I have the impression that the board does not continue to process if it can't get rid of it's output or has a "special mode" if powered by a computer with a potential serial connection in contrast to just being powered by a power source. It doesn't seem to do onInit or load() or might just be blocked by some filled buffer. This is of course just wild black box perspective. At least the buffers seem to get filled and dumped on connect/re-connect.

  • 100uF would be great (I used 47uF), but I'd solder it right onto the top of the ESP01 module. If it goes into breadboard first it might not be as useful.

    I'm very surprised about the Pico reset, but if it can do that then it's not a big surprise the USB connection drops out occasionally. Could it be the USB extension lead you're using has quite a high resistance and can't supply the power required? Just a thought...

    The shims are not yet available directly/from stock somewhere, are they?

    Afraid not... I am planning to add them at some point though. You can still order them relatively cheaply from OSHPark by just uploading the design though

    a "special mode" if powered by a computer with a potential serial connection in contrast to just being powered by a power source

    Yes, it's a bug with the Pico that I'm trying to fix - I think it's mentioned on FAQ/Troubleshooting somewhere. It happens on the original board too, but only if you manage to fill the output buffer. On the Pico it happens straight away. I'm trying to fix it while adding USB HID support, but ST's new USB library is proving difficult to get reliable.

  • Sadly, high resistance USB cables are not unheardof. Extender cables seem to be particularly bad. I have two brands with several-ohm resistance.

  • Hm, I had the same probs when I plugged the Pico directly into the Macbook. With the breadboard ... Shortbread...

    Anyhow, I think it's the cumulation of little issues that bug me to death at the moment. Though that buffer thing is really ugly and uncotrollable (by hand, at least). I tried to upload the Modules by pasting and had to cut everything into such short pieces that even for those small modules it felt kinda stupid. Switched to the WebIDE in the end to upload the modules and save them, to then code in Screen again.

    But if Gordon says "HID Support" and I won't need a Teensy for that, I am happy to wait. Tapping fingers...

  • Have you tried using the IDE's throttle send option? I've never ever had problems sending code to Espruino with that checked (without it, I've had intermittent problems)

    v80 and the current github builds should have USB HID, albeit in a really basic form.

  • I tried that throttle switch, but actually it works fine without that at the moment.

    v80 and the current github builds should have USB HID, albeit in a
    really basic form.

    Ah, Just reflashed to 79 :)
    Any docs on how to use the HID parts/what's there?

  • v80 and the current github builds should have USB HID, albeit in a really basic form.

    It's actually a branch at the moment, so only some of the builds will have it in. I'm having trouble getting reliable USB comms, so I'm not 100% sure when there will be a full release of it I'm afraid.

    The link @DrAzzy posted has a link to a firmware with it working (and hopefully with flow control that'll work for pasting code), but USB HID on that is still a pain, as you need to have the Pico running before you plug in USB.

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

Pico's ESP8266 weirdnesses (Module not found)

Posted by Avatar for Stev @Stev

Actions