#1751 (comment)

wifi.save() does not work:

=function () { [native code] }
>wifi.connect('......', {password: '......'}, function() {
:    console.log('Connected to Wifi.  IP address is:', wifi.getIP().ip);
:    wifi.save(); // Next reboot will auto-connect
:});
ERROR: Wifi: event_handler STA_START: esp_wifi_connect: 12298(SSID is invalid)
=undefined
WARNING: Wifi:startMDNS - espressif
Connected to Wifi.  IP address is: 192.168.1.219
Uncaught Error: File already written with different data
 at line 2 col 15
    wifi.save();
              ^
in function called from system
>wifi.save();
Uncaught Error: File already written with different data
 at line 1 col 11
wifi.save();
          ^
>

Solution: Update to 2v04.401 or newer, go for lastest travis build and require('Storage').eraseAll()

Cannot use sd card. (I'm not sure this is not my fault.) I get:

>SPI1.setup({mosi: SD_CMD, miso:SD_DATA0, sck:SD_CLK});
=undefined
>E.connectSDCard(SPI1, SD_DATA3 );
Uncaught Error: Unimplemented on Linux
 at line 1 col 32
E.connectSDCard(SPI1, SD_DATA3 );
                               ^

Here is the pinout:
i'm using esp32 audio kit, from here: http://wiki.ai-thinker.com/_media/esp32-audio-kit_v2.2_sch.pdf

(sd detect is working)

SD_DETECT=D34;

SD_CLK=D14;
SD_DATA2=D12;
SD_DATA3=D13;
SD_CMD=D15;
SD_DATA0=D2;
SD_DATA1=D4;

Solution: check #1778 for details

save(); does not work

If call save(); ESP32 resets and then I cannot access the uploaded functions...

 2v04.401 (c) 2019 G.Williams
Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/Donate
>Initializing
initializing sd watcher
>typeof watchSDCard
="function"
>save()
=undefined

After that esp32 resets:

Guru Meditation Error: Core  0 panic'ed (LoadProhibited). Excepti.
Core 0 register dump:
PC      : 0x400dd282  PS      : 0x00060130  A0      : 0x800e306f  
A2      : 0x00000065  A3      : 0x3f4064ac  A4      : 0x00000001  
A6      : 0xb33fffff  A7      : 0x00000000  A8      : 0x00000034  
A10     : 0x00000000  A11     : 0x00060023  A12     : 0x00060021  
A14     : 0xb33fffff  A15     : 0x0000000c  SAR     : 0x00000008  
EXCVADDR: 0x00000008  LBEG    : 0x4009b234  LEND    : 0x4009b262  

Backtrace: 0x400dd282:0x3ffde410 0x400e306c:0x3ffde440 0x400e32f60

Rebooting...
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_dr0
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:2668
load:0x40078000,len:7304
load:0x40080000,len:5312
entry 0x40080274
E (38) boot: ota data partition invalid, falling back to factory
E (567) phy_init: store_cal_data_to_nvs_handle: store calibration)


 ____                 _ 
|  __|___ ___ ___ _ _|_|___ ___ 
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 2v04.401 (c) 2019 G.Williams

Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/Donate

E (1177) phy_init: store_cal_data_to_nvs_handle: store calibratio)

>typeof watchSDCard
="undefined"

MaBecker: run require('Storage').eraseAll() to fix this

After some times switching the switch connected to D39 (headphone sense), ESP32 resets.

Here is the code:

DEBUG=true;
HP_DETECT=D39;

var watchHP = function()
{
  if (DEBUG) { console.log('initializing headphone watcher'); }
  setWatch(function(e) {
    if (HP_DETECT.read()===false) 
    {
      if (DEBUG) console.log('headphone plugged');
      HP_PRESENT=true;
    }
    else 
    {
      if (DEBUG) console.log('headphone unplugged');
      HP_PRESENT=false;
    }
  }, HP_DETECT, { repeat: true, debounce: 500 });
};
var init = function() {
  console.log("Initializing");

  watchHP();
};

E.on('init', function() {  init(); } );

init();

Here is the serial coredump:

-> Telnet
Guru Meditation Error: Core  0 panic'ed (Unhandled debug exception)
Debug exception reason: BREAK instr 
Core 0 register dump:
PC      : 0x400803c0  PS      : 0x00060536  A0      : 0x40095224  A1      : 0x3ffe2010  
A2      : 0x8d004136  A3      : 0x00000000  A4      : 0x00000000  A5      : 0x00000000  
A6      : 0x00000000  A7      : 0x00000000  A8      : 0x80093948  A9      : 0x40095224  
A10     : 0x00000000  A11     : 0xffffffff  A12     : 0x400837b8  A13     : 0x00000000  
A14     : 0x3ffc1150  A15     : 0x00000001  SAR     : 0x00000011  EXCCAUSE: 0x00000001  
EXCVADDR: 0x00000000  LBEG    : 0x4009b234  LEND    : 0x4009b262  LCOUNT  : 0xffffffff  

Backtrace: 0x400803c0:0x3ffe2010 0x40095221:0x4011936a

Rebooting...
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x1f (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

Started running device testing from Device Test Harness

run test for https

reduced vars down to 1700

>process.memory()
={ free: 1675, usage: 25, total: 1700, history: 0,
  gc: 0, gctime: 1.269, blocksize: 16 }
>ESP32.getState()
={
  sdkVersion: "v3.1.3-dirty",
  freeHeap: 15904, BLE: true, Wifi: true, minHeap: 13972 }

trying some simple code

var http = require("http");
http.get("https://www.google.com", function(res) {
  res.on('data', function(data) {
    console.log("got data");
  });
});
>Uncaught InternalError: Failed! mbedtls_ssl_setup: Not enough memory
 at line 6 col 2
});

@jumjum123

• What is the reason for using the mbed lib from espressif?
• Can we switch back to the mbed version distributed with Espruino?

slow spi see forum and issues #695 #1212

I summarize the list of hardware functions that I use successfully:

• I use SPI to communicate with SDCard and TFT ILIST7735 screen at the same time
• I use PWM to move SG90 servo
• I use DAC on pin D26 for 8KHz sound from samples in Storage area. It works regular. I am working to make it read from SDCard.
• I use Neopixel with 16x16 matrix, quite well.
• I use I2C with IMU9250 works very well
• SetWatch works well, but it is not well documented that PINs are valid.
• BLE I don't use it yet, it also takes up a lot of JSVars space
• WIFI works very well for me, I use GET requests and receive javascript code via POST
• I work via Telnet, instead of Serial, to assess the stability of the connection.

I am ready for any contribution or details that allow us to advance and improve the ESP32 version.

All these functions have been tested with firmware v2.0.130.

It seems that the latest firmware has problems, and perhaps some functions that I say work, have stopped working.

I have to check with the latest firmware.

This is my actual enviroment :

>process.env;
={
  VERSION: "2v00.130",
  GIT_COMMIT: "9aba654",
  BOARD: "ESP32",
  FLASH: 0, RAM: 524288,
  SERIAL: "30aea432-34b4",
  CONSOLE: "Telnet",
  MODULES: "Flash,Storage,hea" ... "r,crypto,neopixel",
  EXPTR: 1073484860 }
> 

and API

>print(ESP32.getState());
{
  "sdkVersion": "v3.1",
  "freeHeap": 17024, "BLE": false, "Wifi": true, "minHeap": 13848 }
=undefined
> 

I just generated a new Build environment. I have downloaded the latest github and the firmware generated is the following version:

espruino_2v04.406_esp32.elf
esptool.py v2.6
** espruino_2v04.406_esp32.bin uses 1395712 bytes of 1572864 available

I'll do the tests from here ...

So my situation for testing is:

my previous environment where everything works well is:
2v00.130 and ESP-IDF 3.1 dated October 2018

and the new environment is
2v04.406 and ESP-IDF 3.1.3 dated March 2020

The objective is :
2v0x and ESP-IDF 4.x

I publish here the little code that I have tried to use the Touch functionality ...

It is pending to implement it correctly, since it is necessary to define the state of a PIN as TOUCH.

file jswrap_io.c ->

/*JSON{
  "type"     : "function",
  "name"     : "touchRead",
  "generate" : "jswrap_io_touchRead",
  "params"   : [
    ["pin","JsVar","The pin to use"]
  ],
  "return"   : ["int","The touch Value of the Pin"]
}
Get the touch value of the given pin.

*/
JsVarInt jswrap_io_touchRead(JsVar *pinVar)
{
	
	// Handle the case where it is a single pin.
    Pin pin=jshGetPinFromVar(pinVar);
	
	if (jshIsPinValid(pin))
		{
		if (!jshGetPinStateIsManual(pin))
			{
			// RIC Pendiente !!!!!
			// RIC de momento no tenemos estado para definir los Touch PINs
			}
    		
		return jshPinGetTouchValue(pin);
		}
	else
		{
		// Handle pin being invalid.
		jsExceptionHere(JSET_ERROR,"Invalid pin!");
		}
		
}

file in jshardware.c ->

/**
 * Get the touch value of the corresponding pin.
 * \return The current touch value of the pin.
 */
JsVarInt CALLED_FROM_INTERRUPT jshPinGetTouchValue(Pin pin 			//!< The pin to have its value read.
												  ) 				// can be called at interrupt time 
{
		
	// recojemos el numero de PIN en nomenclatura ESP32
	gpio_num_t gpioNum=pinToESP32Pin(pin);
	
	// ahora convertimos el PIN de ESP32 a su numero en el driver de TouchPin
	if (gpioNum == 4)
		{
		gpioNum=0;
		}
	else if (gpioNum == 0)
		{
		gpioNum=1;
		}
	else if (gpioNum == 2)
		{
		gpioNum=2;
		}
	else if (gpioNum == 15)
		{
		gpioNum=3;
		}
	else if (gpioNum == 13)
		{
		gpioNum=4;
		}
	else if (gpioNum == 12)
		{
		gpioNum=5;
		}
	else if (gpioNum == 14)
		{
		gpioNum=6;
		}
	else if (gpioNum == 27)
		{
		gpioNum=7;
		}
	else if (gpioNum == 33)
		{
		gpioNum=8;
		}
	else if (gpioNum == 32)
		{
		gpioNum=9;
		}
			
	uint16_t touch_value=8888;
	esp_err_t estado;
	estado=touch_pad_read(gpioNum,&touch_value);
	if (estado != ESP_OK)								
		{
		// configuramos el PIN, OJO de solo hacerlo una vez !!!
		#define TOUCH_THRESH_NO_USE   (0)
		touch_pad_config(gpioNum,TOUCH_THRESH_NO_USE);
		
		touch_pad_read(gpioNum,&touch_value);
		}
		
	return (JsVarInt)touch_value;
	
}

In case the code is useful for someone to start the implementation

The partition file (BIN) has been modified according to
#1776

but the CSV file detailing the partitions I don't know if it is still correct now.
It should be updated right?

https://github.com/espruino/Espruino/blob/master/targets/esp32/Changes_V3.1/partitions_espruino.csv

I have verified that the original js_code partition started at 0x2C0000

now it has been changed to 0x320000 to leave more room for the firmware.

Doing tests to add Tensorflow I had to increase the space more and I have it at 0x380000 which leaves me 1728Kbytes.

Maybe we could leave a big size thinking about the future.

This is a partition proposal, which I don't know if it supports ESP-IDF 4.x.

An issue that remains in the air is the storage area. Currently if we use SDCard, Storage cannot be used. And since Storage and js_code are similar (do not support rewrite), perhaps they could be merged into one.

Doing tests to add Tensorflow I had to increase the space more and I have it at 0x380000 which leaves me 1728Kbytes.

There is one bitter site on adding function. It reduces the heap and that reduces memory.
These are the two command that will give you information about what is left process.memory() and ESP32.getState()

There is one bitter site on adding function. It reduces the heap and that reduces memory.
These are the two command that will give you information about what is left process.memory() and ESP32.getState()

Yes it's correct. I have not calculated how much heap and JSvar spends. But if it could work as a BLE that can be disabled on reset it is a very good solution.
There are applications that can use it and others that cannot, but better if the possibility exists in the firmware. In ESP32 there are currently no firmware space problems, another is runtime space.

ESP32 and https is all about memory .....

The kicker to get heap memory is to remove this build option

 'DEFINES+=-DJSVAR_MALLOC', # Allocate space for variables at jsvInit time 

and set 'variables' to a lower value like 1800, having compact vars would be helpfull.

test code:

var http = require("http");

http.get("https://httpbin.org/ip", function(res) {
  console.log(res.headers);
  res.on('data', function(data) {
    console.log("got data",data);
  });
});

output:

{
  "Date": "Thu, 23 Apr 2020 05:47:06 GMT",
  "Content-Type": "application/json",
  "Content-Length": "30",
  "Connection": "close",
  "Server": "gunicorn/19.9.0",
  "Access-Control-Allow-Origin": "*",
  "Access-Control-Allow-Credentials": "true"
 }
got data {
  "origin": a.b.c.d"   <- replaced my IP 
}

@jumjum123: What do you think about removing this option?

# before https call
>ESP32.getState()
={
  "sdkVersion": "v3.1.3-dirty",
  "freeHeap": 68796, "BLE": false, "Wifi": true, "minHeap": 62448 }

# after https call
>ESP32.getState()
={
  sdkVersion: "v3.1.3-dirty",
  freeHeap: 62920, BLE: false, Wifi: true, minHeap: 14136 }

JSVAR_MALLOC is all about allowing memory to be allocated as needed - so theoretically it'd be possible to set it up to allocate less memory if you wanted HTTPS, even without a reboot. Maybe via whatever flags are currently used to toggle BLE state?

Toggle BLE cause a reboot.

So let me look into JSVAR_MALLOC and try to make it dynamical. Maybe @jumjum123 can support too.

Does JSVAR_MALLOC is using the conventional allocation or does it use something like compact vars?

EDIT: Ok, so it is not ESP32 specific as it lifes in src/jsvar.c - wrong!

It is used in main.c for esp32 with a heap limitation of 40000.
So let’s increase this value to 60000 and than integreate it into the esp32 board file.

Edit: added test results for different values

// branch: master

 heapVars = (esp_get_free_heap_size() - X) / 16; 

 X = 60000 - https works 

    process.memory():
     { "free": 2738, "usage": 62, "total": 2800, "history": 30,
      "gc": 0, "gctime": 2.208, "blocksize": 16 }
    ESP32.getState():
     {
      "sdkVersion": "v3.1.3-dirty",
      "freeHeap": 51000, "BLE": false, "Wifi": true, "minHeap": 48124 }

 X = 55000 - https fails 

    process.memory():
     { "free": 3038, "usage": 62, "total": 3100, "history": 30,
      "gc": 0, "gctime": 2.427, "blocksize": 16 }
    ESP32.getState():
     {
      "sdkVersion": "v3.1.3-dirty",
      "freeHeap": 47684, "BLE": false, "Wifi": true, "minHeap": 43004 }

// branch: experimental_compact_vars

  X = 50000

    process.memory():
     { "free": 3334, "usage": 66, "total": 3400, "history": 38,
      "gc": 0, "gctime": 3.216, "blocksize": 13 }
    ESP32.getState():
     {
      "sdkVersion": "v3.1.3-dirty",
      "freeHeap": 53388, "BLE": false, "Wifi": true, "minHeap": 47044 }

Summary: Need about 47 KB free heap to run https.

also add these to the list: #1832

Using Storage, it does not take many write/erase cycles to cause an error that results in a reboot.

Test code:

var s    = require("Storage"),

	       //256 Char string:
	temp = "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef" +
	       "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef" +
	       "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef" +
	       "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef",

	writeFile = (id, len) => {
		var a = 0,
			chunkSize = 0;

		console.log("Erasing " + id);
		s.erase(id);

		console.log("Writing " + id);
		while (a < len) {
			chunkSize = Math.min(256, len - a);

			s.write(id, temp.substr(0, chunkSize), a, (a === 0 ? len : undefined));

			a += chunkSize;
		}
	};


writeFile("web_svg", 1131);
writeFile("web_css", 6405);
writeFile("web_htm", 11249);
writeFile("web_js", 26127);

writeFile("web_svg", 1131);

writeFile("fileserv", 3106);
writeFile("jq_small", 859);
writeFile("parsemql", 1103);
writeFile("varint64", 2230);
writeFile("flex_es6", 5590);

while (true) {
	writeFile(".bootcde", 38693);
}

Using Storage, it does not take many write/erase cycles to cause an error that results in a reboot.

This code causes a stack overflow

***ERROR*** A stack overflow in task espruinoTask has been detected.
abort() was called at PC 0x40096ce4 on core 0

If it runs again it also produces

ERROR: >> jshKickWatchDog Not implemented,using taskwatchdog from RTOS

I have spent a lot of time on this stack overflow bug and I think I have exhausted what I can do without help. Here is what I have found so far:

My investigation is focused on jsfCompactInternal() and jsfGetFileHeader() in src/jsflash.c and jsFlashRead() in targets/esp32/jshardware.c.

The stack overflow exclusively occurs when jsfCompactInternal() is called. jsfCompactInternal() calls jsfGetFileHeader() which in turn calls jshFlashRead() and that is when the overflow occurs. There are many other calls to jsfGetFileHeader() and jshFlashRead() that do not result in any problems.

Using uxTaskGetStackHighWaterMark shows that the call stack always has over 21000 words (CORRECTION: bytes) free when jshFlashRead() is called. On occasions when jshFlashRead() is called from any other code, the high water mark is not raised by the call and is largely stable.

My attention is drawn to the input parameters to jshFlashRead(). jshGetFileHeader() passes the arguments addr and header (a pointer to destination) straight through to jshFlashRead() without modification. That makes some sense of why jshFlashRead() only fails when called (indirectly) from jsfCompactInternal() and leads me to try to spot the differences between the calls to jshGetFileHeader(). That's where I am up to because I have failed to spot any difference that I could prove significant.

Anything from a nudge in the right direction from a more experienced Espruino maintainer to a solution would be greatly appreciated at this point.

Thanks for looking into this.

Have you been able to add a jsiConsolePrintf to jshFlashRead to dump the arguments? It may shed some light on what's causing the issue?

It's very odd about there being enough stack free. If not, I'd have put it down to maybe jsuGetFreeStack() at https://github.com/espruino/Espruino/blob/master/src/jsflash.c#L349 not returning the correct value?

In that case I can totally see how it would overwrite the available stack.

Hello everyone,

I haven't written for a long time. I've continued to work on ESP-IDF 3.3.6. I go slow. I'm learning how everything works. And finally I've managed these days to make ESP-IDF 3.3.6 work by myself.

Once achieved, I've started working on ESP-IDF 4.4, which is from January 2022 the same as 3.3.6. I'm making progress even though the BUILD system is different. I've not been able to keep the current makefile. And I'm using the one from ESP-IDF 4.4.

A day ago I started in parallel with ESP-IDF 5.0 stable. The build system is very similar to ESP-IDF 4.4. But the hardware API has changed a lot and the FreeRTOS version too. You've to rewrite a lot of code with the implications that it entails.

At the moment I'm going slowly but well, so I'm going to continue.

I hope to write news not too late.

Hello, I'm still working on ESP-IDF 4.4 and 5.0.

Now working on the analog hardware. I see that only the ADC1 channel is implemented, but not the ADC2. I noticed it when I read the analog value of pin 4, which gave me error.

According to ESP32 we have:
<< The ESP32 integrates two 12-bit SAR (Successive Approximation Register) ADCs, supporting a total of 18 measurement channels (analog enabled pins). The ADC driver API supports ADC1 (8 channels, attached to GPIOs 32 - 39), and ADC2 (10 channels, attached to GPIOs 0, 2, 4, 12 - 15 and 25 - 27). >>

I'm going to add the code for channel 2, it will be useful.

@rgomezwap Nice.

Do you have time to fix some of the errors?

Unfortunately the time available varies from week to week depending on the work.
But since I started the work with 3.3.6 I have not stopped.
Now that I have started I want to get it finished.

Current status of version 4.4.

Testing the hardware. Still a long way to go, but I'm not that far away.

Nice, what about the known errors? Do they still exist with IDF 4.4?

At the moment these are basic tests. There are important modules that aren't included at the moment: WIFI and Bluetooth.

At the moment I have a Espruino Core, only interpreter and REPL. Both in 4.4 and 5.0.

Now adding the basic hardware. This allows me to minimize the number of errors. And see how the memory consumption goes up according to the modules.

Is there a major error I should watch for?

Yes: #2295 plus the Collection of observations at the top

Ok when I add WIFI I will look into this specific problem and say something on #2295 .

Hello,

I am still working. At the moment with ESP-IDF 4.4 adding WIFI.
I have WIFI and EspruinoUART running on Core0 and EspruinoTask on Core1. This way we take advantage of the power of two cores. Especially the WIFI communication does not interfere with the Espruino timings.

But having two cores accessing JsVars at the same time gives problems and I'm looking for a solution. FreeRTOS with SMP systems says to use taskENTER_CRITICAL.

I'll continue to report.

@rgomezwap Any update?

I can't still use any espruino version after the 2.06 because I get a lot error ( guru meditation and psram ) with my esp32 wroom 32

It would be interesting if you can come up with a code example that fails reliably on 2v17 - I have customers using this in production and it's stable for them

It would be interesting if you can come up with a code example that fails reliably on 2v17 - I have customers using this in production and it's stable for them

Hi and thank you for answer me!

I flashed espruino 2v17.56.

Even If I do a simple "console.log("hello world") I got this:

| |_ ___ ___ _ ||___ ___
| | -| . | | | | | | . |
||| || |||||_|
|| espruino.com
2v17.56 (c) 2021 G.Williams
Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/Donate

WARNING: Scan stop failed
WARNING: set rssi scan not implemeted yet
Guru Meditation Error: Core 0 panic'ed (LoadProhibited). Exception was unhandled.
Core 0 register dump:
PC : 0x401126b1 PS : 0x00060c30 A0 : 0x80112e6b A1 : 0x3ffea370
A2 : 0x00000001 A3 : 0x00003fff A4 : 0x00000001 A5 : 0x00000001
A6 : 0xb33fffff A7 : 0x003ffb0a A8 : 0x00000000 A9 : 0x3ffea350
A10 : 0x00000000 A11 : 0x00037ff2 A12 : 0x3ffea364 A13 : 0x00000000
A14 : 0x00000001 A15 : 0x00000001 SAR : 0x00000002 EXCCAUSE: 0x0000001c
EXCVADDR: 0x0000000c LBEG : 0x400924b4 LEND : 0x400924d0 LCOUNT : 0xffffffff
ELF file SHA256: 0000000000000000
Backtrace: 0x401126ae:0x3ffea370 0x40112e68:0x3ffea390 0x40126332:0x3ffea3b0 0x40126491:0x3ffea460 0x401343f8:0x3ffea480
Rebooting...
ets Jul 29 2019 12:21:46
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:2984
load:0x40078000,len:10700
load:0x40080400,len:5236
entry 0x40080658
E (29) boot: ota data partition invalid, falling back to factory
E (561) psram: PSRAM ID read error: 0xffffffff
E (561) spiram: SPI RAM enabled but initialization failed. Bailing out.
E (561) spiram: SPI RAM not initialized

| |_ ___ ___ _ ||___ ___
| | -| . | | | | | | . |
||| || |||||_|
|| espruino.com
2v17.56 (c) 2021 G.Williams
Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/Donate

@rgomezwap Any update?

I can't still use any espruino version after the 2.06 because I get a lot error ( guru meditation and psram ) with my esp32 wroom 32

Hello, the truth is that I got stuck on an error related to the WIFI SCAN callback. And I have started working on the ESP32 S3 version, but compatible with ESP32.

This thread discusses the topic: https://forum.espruino.com/conversations/372053/#comment16953127

But I think the error you have is very specific. I don't think it's from the latest Espruino builds. But I'll try it later to see if it happens to me.

I always do is erase all memory before uploading new firmware. Sometimes things are left in data partitions.

I'm sorry. I just tested it. You are right. I have uploaded the firmware from the link you sent me and the same error occurs.

Let's see if more people say something and we can clarify.

Ok, thank you!

This is a bit frustrating for me because i can't use a recent version of espruino

Ok, I just:

• Downloaded the tgz from https://www.espruino.com/binaries/travis/master/
• Copy/pasted the instructions from the readme there to flash it
• Pasted console.log("hello world") into the console - and it works
• Uploaded console.log("hello world") from the IDE - and it breaks

It seems the issue is reset() has got broken - it looks like for quite some time. I'm just pushing a fix in now - it looks like when others are using it they may have been writing code direct (rather than via the IDE)

I've just pushed a few other changes (getting rid of warnings, adding flow control). Maybe try now - it should be a lot better.

Some the 2v18 release I'll make the Web IDE remove the 'slow writes' it has to add to avoid dropping characters on ESP32, which should make things a lot snappier too. If you use the dev Web IDE from https://espruino.github.io/EspruinoWebIDE/ you can now choose 'Never' for 'Throttle Send' to get it faster before then

I've just pushed a few other changes (getting rid of warnings, adding flow control). Maybe try now - it should be a lot better.

Some the 2v18 release I'll make the Web IDE remove the 'slow writes' it has to add to avoid dropping characters on ESP32, which should make things a lot snappier too. If you use the dev Web IDE from https://espruino.github.io/EspruinoWebIDE/ you can now choose 'Never' for 'Throttle Send' to get it faster before then

Hi!

I just compiled and flashed with your fixes and now it works very well!
I tried the wifi and did a simple web server, it seems stable and smooth!

Thank you so much for the fast response and fixes

@MaBecker I'm trying to get Bluetooth UART working nicely, and while it works well normally, I'm hitting:

Guru Meditation Error: Core  0 panic'ed (Cache disabled but cached memory region accessed)

When sending a lot of data over Bluetooth at once (on WROOM32 or normal). As far as I can tell the error isn't actually in the code that's related to UART, but it's triggered by a libc divide function called by something else in an interrupt.

I did a quick google and spotted a thread mentioning that CONFIG_SPI_MASTER_ISR_IN_IRAM=y caused the issue and you could disable it at the expense of a bit of speed. Any thoughts on this? And am I right in thinking that they change would need a recompile of EspruinoBuildTools?

Actually forget that - I managed to get it working without the timer/interrupt handler and it seems a lot more reliable now!

HI, I added some questions here earlier that Ive just deleted. As all seems to be well now.
I was also experiencing the broken reset issue, with the same error output reported by @lediable above.
But im please to confim that Espruino 2.v.17.71 looks to have fixed it.
Ive actually been trying to get to the root of it for a couple of weeks :( It was only occurring in Espruino V17 and on a WROOM module without PSRAM (It did not occur on a Wrover with 4MB PSRAM) which may help to explain why it was relatively unnoticed.
I think it was probably the cause of the issue in this forum post also. https://forum.espruino.com/conversations/383867/#comment16870364
Thanks for the fix @gfwilliams

At the moment (2v17.71) the only wake mode from deep sleep is timer based. ESP32 boards also have the ability to wake by touch as well as by external interrupt but these are not yet implemented in Espruino.

I have just submitted PR #2358 which implements wake on external interrupt using ext0 (single pin wakeup) which I hope will be considered favourably.

There is a second possible external interrupt wakeup function using ext1 (with bitmask arg for multiple pins) that could also be implemented but I thought I'd wait to see how my first contribution goes. Eventually, wakeup by touch would be nice too.

The project I'm doing that uses the deep sleep stuff needs to know what has caused any wakeup. Therefore I now have another change ready for the ESP32 implementation which exposes esp-idf's esp_sleep_get_wakeup_cause() function as ESP32.getWakeupCause().

My question is whether to submit this change as a new PR or, since this change affects the same files as my PR #2358, to try rolling the new changes into the existing PR?

Thanks for any advice.

Sorry, only just spotted this and merged - I'd make that a new PR. In general if it's possible to do smallish PRs that's probably better - if I can just glance at the file changes and see clearly nothing will have been broken I'm far more likely to just click merge straight away :)

Thanks for these additions. It's hugely helpful to have folks that are willing to contribute fixes when they have problems :)

Thanks for the merge. I've just submitted PR #2359 to add getWakeupCause().

Just merged, thanks! And thanks for the donation too - that was extremely kind of you!