Search results for:

So I just flashed a LoLin ESP8266 board, with 1v99, and tried to replicate your problem. SetWatch performed as expected when connected to Vin or GND. It detected the state change when I touched the pins. I used your code example.

I have worked with setWatch alot on the ESP8266, and its pretty stable. As an example, after I tried to replicate your problem, I wired up a rotary encoder and used the "encoder" module to test. It uses setWatch under the hood. Here is my code (just a copy paste from the "encoder" module page).

var step = 0;
require("Encoder").connect(NodeMCU.D5,NodeMCU.D6,function (direction) {
  step += direction;
  print(step);
});

As you can see I got a couple of errors (probably my pin choices), and a warning about FIFO_FULL, but this didn't affect performance in anyway. I was spinning the encoder as fast as I can. So thats about 22 events in 2-3 seconds, which is not bad. I literally span the encoder as fast as I could and everything was fine. The FIFO_FULL warning only came after a restart of the module. It could perform for hundreds of turns after without problems.

 ____                 _
|  __|___ ___ ___ _ _|_|___ ___
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 1v99 (c) 2018 G.Williams
Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/Donate
Flash map 4MB:1024/1024, manuf 0x20 chip 0x4016
>
=undefined
ERROR: Pin state not supported
ERROR: Pin state not supported
-1
-2
New interpreter error: FIFO_FULL
-3
-4
-5
-6
-7
-8
-9
-10
-11
-12
-13
-14
-15
-16
-17
-18
-19
-20
-21
-22

So this suggests to me Espruino is fine. And that as @allObjects suggested your problem is electrical. Please note, that not all ESP8266 boards are the same or of the same quality. For example both the ESP-201s, and the AT-WITTYs were notoriously difficult to deal with from flash memory corruption to extremely flakey power. Other boards (WeMos D1 Mini comes to mind), operate pretty flawlessly.

Anyways check your setup again I'd suggest.

Great! Good to know! :)

The RST pin is important in the Wifi Kit 32 board, I would assume it is in your case as well.

 I2C1.setup({scl:D15,sda:D4});
 
function start () {
    // put your startup code here. 
}

g = require("SSD1306").connect(I2C1, start,{rst: D16});

There are a series of NRF classes in the reference documents, that I believe the ESP32 uses for Bluetooth. I'm not sure how much of it is fully complete as its a feature in development.

I don't have a LoRa board, so I cannot help you with that one.

Yeah I saw that @JumJum had written the code in one of the Github tickets. I had a look at it, but its using alot of stuff I haven't figured out in the IDF (not that I've done much yet). RMT channels, etc, plus how WS2812s work in general at the protocol level. I might have a look at it over the weekend, see if I can make heads or tails of it.

Hey, pelase see the files attached at the end of this thread and tell me if they work for you. They are supposed to resolve the Wifi, and Bluetooth issues with the Heltec boards.

http://forum.espruino.com/conversations/324188/#comment14397759

Good luck :)

-=hfc

Actually, the component that really matters for the Heltec board is bootloader.bin. Get the latest from Travis. It seems to use a different onboard crystal from most modules. Which board are you using from them, the LoRa board, or the "Wifi Kit 32"?

So I'm driving two different NeoPixel rings from an ESP32 module. They are on different pins. One is a 16 pixel ring, the other is a 24 pixel ring. I understand they can be chained together, however for various reasons this is not my setup.

Basically the problem is that when I write to one Neopixel ring on one pin, using Espruino 1v97, it writes to all the other rings on other pins. I've tried this with up to three rings on three different pins, on several different ESP32 modules. I am using 1v97, as it seems to be the last module supporting WS2812's.

I would like to point out that I have used this setup many times on the ESP8266 and it worked perfectly fine, and I replicated this today just to convince myself. It seems like something that would be an electrical problem, except I've used several different kinds of boards (LinLo, Heltec, WeMos, etc, etc), and the commonality is always the ESP32. The 8266 boards work fine.

Below is the setup and information needed to reproduce if interested.

I have included my wiring diagram -- it can't get more simple then that. Its the same for both the ESP32s and the 8266s.

So take some simple code like this:

// WS2812 TEST

var neopixel=require("neopixel");

// reset the rings, not needed actually
pixels24=[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,];
pixels16=[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,];

pinMode(D12,"output");
pinMode(D14,"output");

neopixel.write(D12,pixels16);
neopixel.write(D14,pixels24);

neopixel.write(D12,[100,0,100,100,0,100]);
neopixel.write(D14,[10,100,50,10,100,50]);

We would expect that at the end of this code the ring on D12, would have two pixels different than the ring on D14 (yes I tried different pins).

On the ESP32 both rings always end up in the same state with the same color. On the ESP8266 modules the rings always end up different colors as you would expect.

I saw there is an open GitHub ticket for WS2812 which seems to have broken since moving to IDF 3.xx, but I wasn't sure if its related as it seems to be an issue on 1v97. I did not have the time to check on earlier versions.

I'd just like to point out that 1v97 works perfectly fine for one array of NeoPixels on one pin. So if any one is able to reproduce this, and or has any ideas that would be helpful, it would be appreciated.

It would be a strange bug in my mind that it would simply affect all NeoPixels on any pins. As I said, I've done multi-ring setups on the ESP8266 (in fact its quite common, as I do NeoPixel lighting for some projects), and I've not seen this issue ever before there.

Thanks!

(Just for fun I included photos from my tests today so you see what I mean in case it wasn't clear. The photo where the two rings have the same color are the ESp32s, etc...)

Also before flashing, its a good idea to erase the firmware entirely. I use something like:

esptool.py --port [insert_port_here] erase_flash

if you're using esptool. I noticed that the ESP32 was more sensitive to this issue (requiring the flash to be erased before uploading the firmware) than the ESP8266.

Yeah, I read they have 3.2 in beta -- so keep your seatbelts on :P

That said, this release has some very interesting features -- if I understand correctly. Specifically:

• Wi-Fi and Bluetooth modem sleep support

• Bluetooth A2DP source support (if this is what I think it is -- pairing with Bluetooth Audio Devices)

• Automatic Light Sleep feature...."Average current in Wi-Fi Station mode, when connected to AP (DTIM=1) is 3.1mA. This is 10x lower than the average current in modem sleep mode under the same scenario (30mA)."

• Wi-Fi mesh functionality (ESP-MESH) (this could be VERY cool down the road...)

@Wilberforce Just as an amusing follow up, I actually TOOK the bootloader.bin from the latest build I did and replaced it with the one in 1v98 which did not work correctly before. I reflashed the board and it worked fine. So the magic does seem to happen in bootloader.bin, at least with regards to these settings.

Also yes the board is very nice as its been designed from scratch around the ESP32. Most of them use a WROOM module then tack on OLED screen, plus Li-Ion charger, and seem kind of monsterous. I'd be curious to try out this board's slightly cooler brother that sports LoRa.

OK. 1v96 might work too. I initially had to flash to 1v96 then up to 1v97.

However, I've included here some files here that I built today (through the help of Wilberforce) for version 1v99 that resolves problems for me on a board with a 26mhz crystal. It might work for you.

Also use "40m" for "--flash_freq" in your esptool, in addition to erasing the flash memory first.

Like this,

esptool.py --port  /dev/cu.usbserial-DN02MPA4  erase_flash

then

sudo esptool.py --chip esp32 --port "/dev/cu.usbserial-DN02MPA4" --baud 921600 write_flash -z --flash_mode "dio" --flash_freq "40m" 0x1000 bootloader.bin 0x10000 espruino_esp32.bin 0x8000 partitions_espruino.bin

Let me know if it works, I'm curious.

Your board probably has a 26mhz crystal, and will only run at the moment with Espruino 1v97. I guess that could change in the next or future release.

Background:

http://forum.espruino.com/conversations/324909/

More here:

https://esp32.com/viewtopic.php?t=2800

So good news! I finally recompiled it on my side with "auto" and....da, da...it worked!

So you may well be right about the "bootloader.bin" situation. It would still be good to get a compile from you as mine was on OS X, but I'd be surprised if they weren't the same.

I also flashed this on a few other boards (that all worked before, so I assume 40mhz), and they're fine, radios etc.

So I think we nailed this one :)

I'll test a few more boards over the week as I do some development work.

Actually thats funny, because the link you gave me above was a direct download to espruino_esp32.bin. Just the one file. There was no bootloader.bin. It could well be thats the case. If you can provide me a link to your bootloader.bin I can try it out. I didn't recompile mine yet.

OK that was a good tip. There were a couple of strange things such as an "apt-get: command not found", which is normal on OS X, but I didn't see where this was coming from -- I could not find it in the build-idf.sh

For the rest it compiled fine! I guess its because I had already installed alot of the requirements from this page when I built it last time:

https://dl.espressif.com/doc/esp-idf/latest/get-started/macos-setup-scratch.html

The weirdness I got was:

WARNING: Toolchain version is not supported: 1.22.0-73-ge28a011
Expected to see version: 1.22.0-80-g6c4433a
Please check ESP-IDF setup instructions and update the toolchain, or proceed at your own risk.
rm: app: No such file or directory
rm: esp-idf: No such file or directory
make: *** [app.tgz] Error 1
../esp-idf/components//app_trace/include/esp_app_trace.h: Path contains '..'
../esp-idf/components//app_trace/include/esp_app_trace_util.h: Path contains '..'
../esp-idf/components//app_trace/sys_view/Config/Global.h: Path contains '..'
../esp-idf/components//app_trace/sys_view/Config/SEGGER_RTT_Conf.h: Path contains '..'
../esp-idf/components//app_trace/sys_view/Config/SEGGER_SYSVIEW_Conf.h: Path contains '..'
../esp-idf/components//app_trace/sys_view/Sample/OS/SEGGER_SYSVIEW_FreeRTOS.h: Path contains '..'
../esp-idf/components//app_trace/sys_view/SEGGER/SEGGER.h: Path contains '..'
../esp-idf/components//app_trace/sys_view/SEGGER/SEGGER_RTT.h: Path contains '..'
../esp-idf/components//app_trace/sys_view/SEGGER/SEGGER_SYSVIEW.h: Path contains '..'
../esp-idf/components//app_trace/sys_view/SEGGER/SEGGER_SYSVIEW_ConfDefaults.h: Path contains '..'

pages and pages of that.

Anyways so the results! Good and bad!

Basically the build you made for me didn't work. I assume it had the auto detect frequency settings like you had said (and I saw this in the IDF config). It had the same problem as all the other builds.

So now with my handy handy build-idf.sh script, I was able to compile it with the crystal set to 26MHZ -- and it worked! Wifi radio is fine, Bluetooth can find things easily. Baudrate is 115200 :P

So thats good and bad, because its good for me, but not good for putting out one build for all crystal types. I have to run out now, but I will try a few different things later to see if I can find out why the autodetect didn't work. I can just try building it again with those settings actually, I didn't try it yet, just having used the one you offered me.

I also have contacts here at Espressif (I'm based in Asia at the moment), and could try and ask them if I want to go deeper I guess.

So for me -- great! Thank you so much.

As for generally building the OS X version, I'll review the info on the on Espruino about building, and see if there is anything that should be changed. It would be ideal to run it on a "virgin" Mac, that hadn't had this stuff built on it before to see where it could go really wrong.

OK this is super interesting, especially the updates to the provision script (I really love this script, btw). I manually built the IDF the other day on OS X by "hand", but kind of stopped after I got a basic app template. There was alot to configure from scratch - and actually looked like "work" as opposed to "fun" :P

Let me take sometime this weekend to review, and try the code on the new board. I'll report back :)

Ah, I see see it seemed to have failed somewhere at the linker phase. Anyways if you get it going I'll for test it out also on a few different ESP32 boards, so we can see if it works universally.

Wow thats amazing -- I'm ready to try it out -- too bad it failed. :/ What was the problem I'm just curious (when you get around to it).

Yeah -- I did suspect that changing the settings in sdkconfig.h wouldn't do anything, but it was worth a shot right? :P And I learned about the ESP32 SDK which caused me no harm ;)

Yes I did try the ESP32.enableBLE(false) -- it didn't change anything. The problem is really deeper I believe.

@Wilberforce So just to wrap up this topic for posterity, after spending an evening investigating, I found a couple of things.

First of all the board does work with 1v97 and earlier. The reason it did not work before on 1v97 was I was using a later build (non release), that had Bluetooth. The non Bluetooth version works fine.

When investigating the difference between Arduino and Espruino, I saw that in sdkconfig.h (located in "app/build/include" in the Espruino SDK), the config is set to:

"#define CONFIG_ESP32_XTAL_FREQ 40"
"#define CONFIG_ESP32_XTAL_FREQ_40 1"

Where as in the Arduino sdkconfig.h the settings are:

"#define CONFIG_ESP32_XTAL_FREQ 0"
"#define CONFIG_ESP32_XTAL_FREQ_AUTO 1"

The official docs from Espressif say you can have 40mzh, 26mhz, 24mhz, or "auto".

I changed the settings actually and did a few recompiles and flashings, none of these made any difference. The baud rate on my board was stil 74880, and the radios didn't work. Wifi returned nothing, and Bluetooth worked maybe 10% of the time. I can't confirm that Bluetooth worked on 1v97, obviously, as the non Bluetooth build was the only one which seemed to function "normally".

So adding the Bluetooth code definitely is the marker in the build progression where this started. While for sure it is just one board, as we saw there is also at least a Sparkfun ESP32 module that has a 26mhz crystal. Maybe something to look at when everyone has time, I know there are alot of other priorities in this great effort you and JumJum are doing. I am curious what the change was with adding the Bluetooth code.

There's a parameter in the Espressif IDF that can set the crystal frequency, and apparently has an "autodetect"setting. Its mentioned that Arduino also "autodetects" the crystal frequency. I have no idea how thats done.

https://github.com/espressif/esp-idf/issues/1351

The above thread actually deals exactly with this Heltec board. Unfortunately my Espruino SDK is built using a downloaded "prebuilt" IDF for OS X. In theory I could recompile it, with the right flag ("esp32-xtal-freq-sel") from scratch, but I'd have to look at what that would involve, so I cannot test this at the moment.

@Gordon, thanks, thats very helpful -- I'll try that in the future, and make a note of it.

@Wilberforce -- thats funny you mention that -- the WiFi doesn't return any values on this board it turns out. There are no errors, but everything like wifi.scan() etc returns null, and its unable to find any APs. Subsequently it can't connect to networking. This is in Espruino. However I flashed it with some test programs on Arduino, and the wifi is working fine there. It can scan and find base stations. I had originally thought that it was because the board is running at 240 mhz, rather than 160mhz which is set in the ESP32.py board definition, but after reading your post...

Is there anything in the ESP32 code that is timing dependent with regard to the wifi?

Hi guys,

So I recently bought one of these very gorgeous and feature packed boards, based on their LoRa module (this one has no LoRa radio).

http://www.heltec.cn/project/wifi_kit_32/

It incorporates: a LiPo battery charger, USB interface, what appears to be a custom made OLED screen (128x64), which looks very cool (brighter and sharper than some I've used), its extremely compact for an ESP32 board...and finally...its WHITE(!).

So long story short, I flashed it couldn't communicate with it. I would type something and get garbage back.

rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:2364
load:0x40078000,len:0
load:0x40078000,len:10880
entry 0x40078c4c
ž›#$„|óBnàän΃oãäûooNrƒNNŒooŸlnî‚N“oâ|‚“‚œl’ƒ’`rlïoÿäŽp’`䛲’ìd ð䓒’ì’’첒äòû’’ì²’$`ðìÛòlb„"äŒB“`ðò“›²ò›Ûì2òû’’òó2ò’› ódœ|€c²Ÿä|óocp~’nd$Œ¾ãäbpƒbpc„lä|ì’äpƒoì’N|sdrl{"’ooNln|äl“ãoä“nò#r’œbìdû„ì¾BrNlo|ä’òN|›‚œl~ãoNüŒpãäƒoãŽìoœänܜänàp„óoà„‚slâNÜœNNà2oNn|ìl `ƒ‚žbìccãŽcÛNnocp~’ncNnà²œlrdü$~ócocBnbcNldBnc$$ll#lll# 

I suspected a baud rate problem but none of the baud rates in the Web IDE worked. I eventually brought up ESPlorer which is a JAR file (can be found online), and had success connecting at 74880.

After I had to go through the Espruino Web IDE code to figure out to change this line:

  function init() {
    Espruino.Core.Config.add("BAUD_RATE", {
      section : "Communications",
      name : "Baud Rate",
      description : "When connecting over serial, this is the baud rate that is used. 9600 is the default for Espruino",
      type : {9600:9600,14400:14400,19200:19200,28800:28800,38400:38400,57600:57600,74880:74880,115200:115200},
      defaultValue : 9600,
    });

...and it works now.

Connected to port /dev/tty.SLAB_USBtoUART
>*«PªV¡¡ET¡Q«UU«T¢Ô-«QR©š«Tš«ªRUJªªV¥Z¹j¡ªTÕJ¨R®J¢•®Ô5TªT©µUµ­Å-QBUª«j”ªªEJªR­Z¹QÊWÕ­Q(©uT«Z¹QJ-]ªZ‹,QRªR­Z¹QÚ¬R­Z¹QQT®UZª¦B)µ©…ªÕ­%µ(Õªª(¥©UVK%µ(Õªª(¥J©jZU•%µ(ՔTQeQRªÕTTªT‹,EÔYQ©UV+QYEj´«P±EÔYJ¥QüWARNING: has simple connection not implemented yet
 ____                 _
|  __|___ ___ ___ _ _|_|___ ___
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 1v97.114 (c) 2018 G.Williams
Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/Donate
>
=undefined
>
=undefined
> 

I've flashed quite a few ESP32s (dozens?), and this is the first time I've come across this situation.

I am curious how Espruino sets its console communications baud rate, and as we can see above when I had the wrong baud rate, the module would boot at 115200 baud, showing me power on information, then I assume switch to 74880 and produce garbage.

Additionally this brings up the question of if we should add "custom" baud rates to the Web IDE console. I know the ESP32 can communicate at up to 921600.

NOTE: This issue occurred through 1v97 to 1v99. I'm flashing to 1v97 here because of the neopixel problem in subsequent releases.

-hfc

Yeah this has happened to me too a few times. If I see anything that reproduces it reliably I'll post something.

Love it :)

It would appear -- happily -- that the new Storage library in 1v96 solves these problems elegantly. I can even write files out to a lowly ESP-01. Not sure if you've used it yet. :)