Most recent activity
-
(argh, forum ate a longer response, so just a short answer now:)
Works on my machine :)
My machine now includes ESP8266, ESP32, nRF52. JSON.parse(undefined) doesn't cause a reboot.
Most likely some other code either in the init or in the "regular" part of your program that causes a reboot. Some other error, or stuck in an infinite loop waiting for something that never happens because init failed (and rebooted by watchdog).Even tried this on an ESP8266 (with save to flash)
function onInit(){ print('@onInit'); //throw new Error('b00'); JSON.parse(undefined); }Output:
____ _ | __|___ ___ ___ _ _|_|___ ___ | __|_ -| . | _| | | | | . | |____|___| _|_| |___|_|_|_|___| |_| espruino.com 2v01 (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 0xef chip 0x4016 > Running onInit()... @onInit Uncaught SyntaxError: Expecting a valid value, got undefined at line 1 col 10 undefined ^ in function called from systemAnd works just fine.
-
Use WSL as @Wilberforce already recommended. Or of course you can use an Ubuntu VM. You can use VS Code with the remote WSL extensions, makes modifying files much easier...
Just install WSL, VSCode, "Remote - WSL" extension
- Start a new VSCode & launch WSL
- open the terminal in VSCode
cd ~(if you are not there by default)git clone https://github.com/espruino/Espruino.git- Press the "Open Folder" button
- and follow the Linux instructions :)
One rookie mistake I did: don't try to use WSL in your regular windows file system (by default you are at something like
/mnt/c/something==c:\something). Clone the Espruino repo into a WSL directory, otherwise bash scripts just went crazy.As for debugging: AFAIK you won't be able to single step debug the Espruino code as easily as you could do from VS. There
gdb, but that itself has a steep learning curve afaik. - Start a new VSCode & launch WSL
-
Yes, I too struggled with this couple of times.
Than discovered there is aREADME_flash.txtin the ESP32 directory that shows pretty much the commands you used.
IIRC, saw somewhere that first you have to flash all parts as above, and after that you can just flashespruino_XvYY_esp32.binto upgrade.Actually the docs tell you to do this, but starts with building from source. So splitting
BuildingandFlashingto separate paragraphs would be a good idea IMO. Or even better, moving the Build instructions down, and only showing the download & flashing instructions in the "Getting Started" sections would make it clearer. Maybe the docs were not updated since ESP32 builds are available...You can always send a PR https://github.com/espruino/EspruinoDocs/blob/master/boards/ESP32.md :)
-
- 1 comment
- 59 views
-
Looks like if I disable BLE and disable Wifi, the ESP32 goes into an infinite reboot loop.
>ESP32.enableBLE(0) ... // normal reboot ... >ESP32.enableWifi(0) Erasing saved code. Done! ets Jun 8 2016 00:22:57 rst:0xc (SW_CPU_RESET),boot:0x13 (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:2668 load:0x40078000,len:7304 load:0x40080000,len:5312 entry 0x40080274 E (545) spiram: SPI RAM enabled but initialization failed. Bailing out. WARNING: Bluetooth is disabled per ESP32.enableBLE(false) Guru Meditation Error: Core 0 panic'ed (StoreProhibited). Exception was unhandled. Core 0 register dump: PC : 0x400d8b18 PS : 0x00060b30 A0 : 0x800d915b A1 : 0x3ffde6c0 A2 : 0x00000001 A3 : 0x00001e78 A4 : 0x00001000 A5 : 0x00000000 A6 : 0x3ffc40cc A7 : 0x3ffd6934 A8 : 0x00000000 A9 : 0x00000001 A10 : 0x00000000 A11 : 0x0001e780 A12 : 0x00000005 A13 : 0x00000000 A14 : 0x00000000 A15 : 0x0003ffff SAR : 0x00000019 EXCCAUSE: 0x0000001d EXCVADDR: 0x0000000e LBEG : 0x4009b418 LEND : 0x4009b423 LCOUNT : 0xffffffff Backtrace: 0x400d8b18:0x3ffde6c0 0x400d9158:0x3ffde6e0 0x400f85e5:0x3ffde700 Rebooting... // and this goes on...Only way to recover is to erase + reflash the ESP32.
Tested with 2v01 and 2v04 with two boards:
- Generic ESP32 "dev board" chip reported by esptool: ESP32D0WDQ6 (revision 1)
- TTGO Lora32 v2.0 ESP32-PICO-D4 (revision 1)
Ran into this earlier, just ignored... The Chip running hot on blink sketch thread was the final push to re-test this again.
Can someone else confirm this? Any idea how to fix? - Generic ESP32 "dev board" chip reported by esptool: ESP32D0WDQ6 (revision 1)
-
I don't have any boards right now with me, but in #4 I measured the "idle" and "blink" power consumption of ESP32 & MicroPython board.
In "idle" - connected to the REPL via USB - no code running, but ready for input, I measured 48mA.
With the "blink" code from #1 withtime.sleep_ms(1000), I measured 50mA.
That's ~1/3 of Espruino's power consumption.Looked at Espruino's ESP32 code, and as far as I can tell, Espruino does not go to sleep mode with the ESP32 port at all. In ESP32 jshardware.c
jshSleepdoes nothing. In other boards it does a bunch of checks, and goes to sleep if nothing is going on. For example nRF52Not sure what MicroPython does so far, and don't have a real micropython board to check their power consumption. But reading the docs, it looks like it doesn't go to sleep by default as much as an nRF Espruino, you have to explicitly send to sleep if you want to achieve really low power. "Just idles".
But what is not right: According to the ESP32 datasheet, the power consumption in "modem sleep" with dual cores running at 240MHz should be 30-68mA. (the highest without radio). MicroPython is in this range. But in my measurements Espruino by default is well over this range. Ok, I must admit, I can't reliably switch off BLE and Wifi the same time. Goes into an endless reboot loop, and only reflashing helps. (I will post the console output later).
So my hunch is the Espruino ESP32 maybe doesn't turn off the radio? Ok, probably does not make any difference if you are using Wifi... -
@allObjects regarding Micropython power consumption & sleep: Maybe you missed, but EPS32 Micropython idling in it's repl did consume less power than the code with sleep (48mA vs 50mA). So it's not the
sleepin the code that reduces power consumption significantly. And both was about 1/3 of Espruino's idle power consumption.In Espruino ESP32 as far as I can tell, all tasks are pinned to the first core. You can make it run single core by setting
CONFIG_FREERTOS_UNICORE=yin sdkconfig. And that's supposed to save some power. Tried to build it, but looks like the build just ignored that.
Must have edited the wrong file, because the build went on just fine, even if I added some garbage to the sdkconfig file. Where is the sdkconfig used by the build?Moving forward: both Espruino (on other boards) and Micropython does like a dozen checks before going to sleep. That was the point when I quit :)
Oh, and there is this issue in MicroPython that shows a bug with multi-core ISRs, so it's far from trivial...
-
Ok, did some testing, and can confirm @Linyx's findings with the DHT22:
- MDBT42Q module (2v04) - works flawlessly
- ESP8266 - I have one that's been running for months without issue
- ESP32 (tested with 2v01 and 2v04) - doesn't work.
Checked the communication with a logic analyzer, and the DHT22 sends the right response (temperature and humidity valid, checksum ok). It's just the ESP32 can't pick up the response properly.
Anybody any idea?
- MDBT42Q module (2v04) - works flawlessly
-
Do you have a pullup resistor (4k7 - 10k) between the data and VCC?
IIRC without an external resistor, it didn't work properly with the ESP32, I think it's internal pullup resistor is not strong enough.
Ok, looks like the 2v04 "_4mb" build crashes.
Same ESP flashed with different builds:
-> works
-> works
-> crashes
-> works