Chip running hot on blink sketch

Hello,
My ESP32 (TTGO) is running hot, and I think it causes eventual reset.
I first noticed it running complex code (sensors, WIFI, web server etc.) - it reached ~65 Celsius.
So just to test I run simple blink sketch:

function onInit() {
    let ledOn = false;
    setInterval(() => {
        console.log(`temp = ${(E.getTemperature() - 32) * 0.5556}`);
        digitalWrite(13, ledOn);
        ledOn = !ledOn;
    }, 1000);
}

Surprisingly even on above it reached 62 C.

I made same test with Mircopython:

import esp32
from machine import Pin
import time

led = Pin(13, Pin.OUT)

while True:
    led.value(not led.value())  
    print((esp32.raw_temperature() - 32) * 0.5556)
    time.sleep_ms(1000) 

gave me: 51 C

Arduino:

void setup() {
  Serial.begin(115200);
  pinMode(13, OUTPUT);
}

bool state = false;

void loop() {
  state = !state;
  digitalWrite(13, state);
  delay(1000);
  Serial.println((temprature_sens_read() - 32) * 0.5556);
}

gave: 53 C

Any ideas?

Wed 2019.08.14

Was the disclaimer read?

http://www.espruino.com/Reference#l_E_ge­tTemperature

I ran an ESP32 for weeks without problems (after I fixed wifi disconnect and MQTT memory leak...). 65°C shouldn't be a problem for an uC. Unless it's really hot there, and gets even warmer :)
On my ESP projects, I send free memory with sensor data, so it's obvious if I have a memory leak. Helped to correlate wifi disconnects with memory leaks and that eventually lead to some fixes in the tinyMQTT library.

Back on topic:

Do you have a multimeter, or a USB power meter to check the power consumption?
First, run ESP32.enableWifi(0), because by default wifi is enabled. (The setting is saved in flash, and resets the ESP32, so just run it once, not in your onInit!)

And my second guess (absolutely not sure about it) would be that arduino and/or micropython disables the second core, while Espruino not. But it's just a guess. Haven't checked on either platform.

@Robin, I think if @pankleks doesn't have some means to measure power consumption, temperature is the second best indication of power consumption.

Oh, but I do have a power meter :) And no LED on pin 13, so the LED doesn't interfere with power measurement :)

• Holding reset: 8mA (Wroom32 devboard with CP21x serial)
  
• Espruino Wifi off & blink: 135mA (127mA over baseline)
  
• Espruino Wifi on & blink: 150mA (142mA over baseline)
  
  

142mA / 127mA is 11.8% difference, but that's probably not enough difference to get the temperature differences you reported...

After 8 minutes the ESP32 reports 38°C with 23°C ambient. What is your ambient temperature? Is it stable during the measurements?

• Micropython idle: 48mA (40mA over baseline)
  
• Micropython blink: 50mA (42mA over baseline)
  
  

Yepp, that's a significant difference! I guess python goes to sleep while Espruino on the ESP32 doesn't.

It's getting late to check arduino but if you don't have a power meter & upload the compiled sketch, I will try that tomorrow.

@AkosLukacs thanks, ambient is around 25 C.

@Robin all 3 measurements were done during same time / same board - so absolute value is not important, more difference between measurements.

@AkosLukacs Made test with WiFi disabled, temp is 59 C - but ambient is also lower (few hours later than first test) so not sure if it's due to WiFi or ambient.

@AkosLukacs

Yepp, that's a significant difference! I guess python goes to sleep while Espruino on the ESP32 doesn't

Looks like significant problem for power consumption - how can we raise this issue? sorry still new here :)

(EDITED) A hot MOS device means it is very busy... surprised that Espruino is not sleeping, since it is core to its design. Something w/ the port is off... or open / noisy inputs may drive it nuts... I guess you are aware of setBusyIndicator(); setSleepIndicator(); - https://www.espruino.com/Reference#l__gl­obal_setBusyIndicator - which gives you hint about when Espruino is and is not busy.

@JumJum, would you have some insights to share about this ESP32 Climate Crisis?

Try disabling BLE. I noticed it ran hotter when this was added to the firmware

@Wilberforce I did all my original tests with BLE disabled, then for later test (based on @AkosLukacs sugestion) I also disabled Wifi - but no significant change in temp.

Have you tried putting all unused pins to output?

The ESP8266 gets warm as well - I didn't try it with NodeMCU but I'm pretty sure it would be cooler, too: The ESP8266 and ESP32 support multiple sleep modes, on Espruino only deepsleep() is implemented (deepsleep stops the processor, WLAN etc. and reboots it to wake up). The other sleep options are not available, and as such the processor is always active. In Micropython you used the sleep() function, no wonder it's using less energy and keeps cooler. If you would implement the Micropython version without sleep() the power consumption and temperature should be equal to the Espruino.
So I wouldn't say it's a bug, but the intended operation for the - obviously limited - builds for ESP8266/ESP32.

Power consumption is one aspect of the whole package... JavaScript has the benefit for the application not to have to deal with concurrency on the low(er)-level API of the underlaying infrastructure... a core goal of @Gordon's design and implementation of Espruino. @Gordon went even further and also picked something that is by nature low power, and consistently, otherwise he would not have chosen MDBT42Q to be the heart of puck.js and pixl.js... and in addition to it: miniaturization... bot not so much claimable by ESP32... considering predecessor ESP8266.

In order to not loose out on many things and very importantly communication, @Gordon has picked the best options and integrated them - Espruino-Wifi - or made them easy to use w/ the libs for ESP8266 hiding its AT protocol. You can do even certs / https - something that ESP8266 is able to do (doing lower level programming than Javascript / Espruino, but with all loaded runs out memory to do... (see Andreas Spiess' youtube clip #232 How to secure our devices using SSL (ESP8266, ESP32, Tutorial)
very well explained what's about w/ SSL).

In real world, @pankleks ' code example for measuring power is not representative at all... especially when thinking of doing a lot of things well organized and not just sleep and once in a while switch a LED on or off. To achieve this low power, @pankleks has to use low level programming of multiple tasks and synchronization there of,... something that for sure is not a makers goal. Not everyone wants to dive int to into the challenges and practices faced in an 'RTOS'. @Gordon has picked the Javascript paradigm of being physically single threaded and added the logical - perceived - multi-threading to support event-driven-ness that is not supported by any of the other implementations, except you go for it (sleeping in the - Arduino / C - main loop is just not an option for a real application...) nor is synchronizing multiple multiple tasks (in micro-python).
ESP32 (and ESP8266) will run as hot as with Espriuno when actually doing something. Implementing Espruino's low power and event architecture all the way thru on ESP32 is a bit more challenging because of the ESP libs and last but not least the dual core... all to be taken into account. I'm sure it will get better over time... by contributions of many interested in Espruino on ESPs

As much as the power of ESP32 is desirable and convenient, it requires the absence of low(est)-power requirement under the presumption to be simple in programming.

@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 sleep in 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=y in 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...

Depends, on how you create firmware.
If you use Espruino Build Tools, there is a precompiled lib and sdkconfig

Otherwise you have to setup a local platform, run through make sdkconfig, etc.

AFAIK, ESP-IDF uses 2nd core for wireless tasks.

Well @maze1980 and @allObjects I do understand sleep vs setInterval + event loop in JS differnces.

Still I don't understand why following code in micropython:

led = Pin(13, Pin.OUT)

def blink():
  led.value(not led.value())  
 
t = time.ticks_ms();
while True:
  if (time.ticks_ms() - t >= 1000):
    blink();
    print((esp32.raw_temperature() - 32) * 0.5556)    
    t = time.ticks_ms()

produces same 51 C

I clearly I'm not putting ESP to sleep, and in a sense it's more or less what main event loop + setInterval would be doing.

@pankleks, to understand what you are stating:

Both micro python codes of post #1 and post #16 produce the same temperature of 51 C?

If so, is a mystery to me too, because as you say: you go not to sleep, you just check time over and over until satisfied.

This makes me conclude 2..3 things:

• micropython implements the sleep just as you did with your time tick check (hard to believe... since python can do better... last but not least because it has multi threading and use timers/interrupts, etc... but why not go the cheap route? ...did not take a look at its implementation)
  
• running Espruino keeps something else powered / alive that produces the heat...
  
• in addition to 2nd bullet item, Espruino also does implement setInterval() without timers (which I hardly can believe... since it used timers/interrupts from the very beginning... but it may not use hw interrupts but software interrupts... I did not look (yet) at the implementation either... so I may be totally off... :/ )
  

@allObjects - just tested code from #1 and #16 again:

• micropython (#1) -> 51 C
  
• micropython (#16) -> 52 C
  
• espruino (#1) -> 61 C (both BLE + WIFI disabled)
  
  

I did not ground all the pins - so there might be noise, but conditions were the same for all tests. I also ordered USB power meter - so when it arrives I will check real power usage.

Usually one core takes care of the app, the other of some stack components... even though both BLE and WiFi are off - to be assumed on the other core - I think there is still something on and going on on that core when Espruino is going. Putting the input pins on input_pullup or input_pulldown - what ever is available - could make a difference. But thank you fort the measuring again and confirming.

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 with time.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 jshSleep does nothing. In other boards it does a bunch of checks, and goes to sleep if nothing is going on. For example nRF52

Not 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...

Any updates on this? Can I help somehow? I'm still waiting for USB power meter so I can provide more precise data.