ESP8266 Community Forum

- Thu Feb 27, 2020 12:59 pm #85881 Hello,
new to ESP environment I am looking for the way to debug an error memory E:M 528
I use NONOS SDK V2.0.0
Is there anybody who can show me doc or tool for this ?

More context :

Code: Select alluser_esp_platform_connect, (user_esp_platform.c, #2060) : user_esp_platform_connect
user_esp_platform_connect, (user_esp_platform.c, #2061) : free heap 23536
client handshake start.
espconn_mbedtls.c 652, type[RootCertificate.cer],length[969]
E:M 528
client handshake failed!
Reason:[-0x4290]
user_esp_platform_recon_cb, (user_esp_platform.c, #1981) : user_esp_platform_recon_cb err 46



user_esp_platform_connect, (user_esp_platform.c, #2060) : user_esp_platform_connect
user_esp_platform_connect, (user_esp_platform.c, #2061) : free heap 22960
client handshake start.
espconn_mbedtls.c 652, type[RootCertificate.cer],length[969]
E:M 528
client handshake failed!
Reason:[-0x2700]
user_esp_platform_recon_cb, (user_esp_platform.c, #1981) : user_esp_platform_recon_cb err -39
user_esp_platform_reconnect, (user_esp_platform.c, #848) : user_esp_platform_reconnect


In another build, without significant change in code, I get "client handshake ok!". I tried optimizing with -O1 instead of -O2 and get the same E:M.

Thanks and regards

- Thu Feb 27, 2020 6:40 pm #85884 In your other build, are you connecting to the same site?

Try increasing the SSL heap value using

Code: Select allespconn_secure_set_size(ESPCONN_CLIENT, size);

- Fri Feb 28, 2020 4:06 am #85888 I'm getting that error when heap memory allocation fails cause there is not enough memory...
(even if you seem to have plenty of that but possibly tls is using a lot of ram)

In my case I found that most of ram memory was used by strings (almost 20 kB...) as by default the compiler put those into rodata segment in ram

I used the example of os_printf into osapi.h (look for USE_OPTIMIZE_PRINTF) to move strings to a different segment into flash memory

Code: Select all#define IROM_TEXT __attribute__((section(".irom.text")))
#define ALIGNED_4 __attribute__((aligned(4)))

// MACROS FOR PLACING STRINGS INTO FLASH MEMORY

// using fs_sprintf keep fmt len under 70 chars
// otherwise a read exception will occur
#define fs_sprintf(buf, fmt, ...)                             \
  do                                                          \
  {                                                           \
    static const char flash_str[] IROM_TEXT ALIGNED_4 = fmt; \
    os_sprintf_plus(buf, flash_str, ##__VA_ARGS__);           \
  } while (0)

#define fs_printf(fmt, ...)                                   \
  do                                                          \
  {                                                           \
    static const char flash_str[] IROM_TEXT ALIGNED_4 = fmt; \
    os_printf_plus(flash_str, ##__VA_ARGS__);                 \
  } while (0)

#define f_str(str) ({ static const char flash_str[] IROM_TEXT ALIGNED_4 = str; &flash_str[0]; })


examples of os_printf and os_sprintf are trivial, f_str used like this

Code: Select allos_strncpy(sensor->name, f_str("DHT11"), 6);

https://github.com/quackmore

- Mon Mar 02, 2020 4:51 am #85907 Thanks for the tips quackmore.
However I regularly check for the free heap and tried also disabling all traces and I still reach same behaviour and depending a little on the build.
I always use same site.
What does mean the number after "E:M" ? I get E:M 0
In fact I found the handshake can fail depending also the execution.
At the moment, difficult to discuss more about those failing experiences.

I would like to discuss an other unwanted behaviour :
with MQTT code enabled, the orignal TLS link is longer to establish connexion: It is frequent to get error -11 from espconn_regist_reconcb (called about each 10 sec. for 1 to 2 min)
Any idea ?
(MQTT does not use secure link)