Isn't reset cause 2 a fatal exception? Is the decoder confused and it's not about the WDT?
--------------- CUT HERE FOR EXCEPTION DECODER ---------------
ets Jan 8 2013,rst cause:2, boot mode:(3,6)
load 0x4010f000, len 3460, room 16
tail 4
chksum 0xcc
load 0x3fff20b8, len 40, room 4
tail 4
chksum 0xc9
csum 0xc9
v000dd7e0
~ld
could also be something unrelated corrupting memory so there is swdt? hostByName works-for-me at least standalone, esp_delay callback returning true as well
not necessarily, but might be an easier answer. corrupting something, forgeting to initialize stuff... also notice esp8266/Arduino#8393 update that fixes compiler bug with -Os
having noticed some c-specific flags in platform.txt and lwip builds... why is .c set to have -fno-inline-functions?
why is .c set to have -fno-inline-functions?
I think it is historical and probably meant to save space back then.
We could remove it but the effect will be little since all
.c files were converted to .cpp files quite a time ago.
true. I though that might do something when including local llhttp's .c files for parsing. zero difference between this option on or off
lwip & bearssl might need testing though
LWIP and BearSSL are built outside of the Arduino platform.txt so don't have this flag set anyway.
gcc options for lwIP are legacy from lwip1.4 and this option is still there
D'oh! Well, not in BearSSL. In any case, changes to platform.txt will not affect them.
Also, I’ve been tracking some challenges connecting ESP8266 to ASUS routers. Does anyone know if this was ever resolved?
I have
volatile int32_t lastmu = 0; // read only outside
void IRAM_ATTR isr(void) {
static int32_t currentmu = 0;
// do something with currentmu... not shown
if (somecondition) {
lastmu = currentmu;
currentmu = 0;
}
}
void init() {
attachInterrupt(digitalPinToInterrupt(somepin), isr, RISING);
}
void fetch() {
int32_t data = lastmu;
}
as far as I see, assignments to int32_t are not atomic. Any suggestion how to handle this the proper esp8266 way?
It's a single core SoC if fetch is not in a higher level ISR there is no way the the code above does not work
- it's a 32-bit CPU, so int32 assignment is 1 CPU operation
I would say, that if the above gives you weird results, then something might be wrong with the
not shown code
I was looking at the generated asm code and it is a little bit overwhelming...
int32_t aaa = somevar; might not be, depending on where somevar is stored
in both cases
aaa will be changed in a single cycle
but in second case there might be a separate fetch operation for
somevar
bedtime. bye. and thanks @drzony
So one esp8266 retrieved from network and then transmits to the next one that only has ESP NOW connection
Hi, I've been getting this SSL error, but the cert is not invalid, and the certstore isn't actually accessed (I log every access to the hook functions), can someone help me understand the best way to debug this please?
[hostByName] request IP for: iop-monitor-server.tk
[hostByName] Host: iop-monitor-server.tk IP: 104.236.4.125
:ref 1
BSSL:_connectSSL: start connection
_iobuf_in: 0x3fff441c
_iobuf_out: 0x3fff8574
_iobuf_in_size: 16709
_iobuf_out_size: 597
[TRACE] TRACER: Entering new scope, at line 59, in function virtual void iop::CertStore::installCertStore(br_x509_minimal_context*), at file cert_store.cpp
[TRACE] TRACER: Free Stack 1988, Free DRAM 11552, Biggest DRAM Block 11280, Connection 1
[TRACE] TRACER: Leaving scope, at line 59, in function virtual void iop::CertStore::installCertStore(br_x509_minimal_context*), at file cert_store.cpp
BSSL:Installed certstore
:wr 226 0
:wrc 226 226 0
:ack 226
:rn 536
:rd 5, 536, 0
:rdi 536, 5
:rch 536, 536
:rd 85, 1072, 5
:rdi 531, 85
:rch 1072, 536
:rch 1608, 536
:rd 5, 2144, 90
:rdi 446, 5
:rd 2049, 2144, 95
:rdi 441, 441
:c 441, 536, 2144
:rdi 536, 536
:c 536, 536, 1608
:rdi 536, 536
:c 536, 536, 1072
:rdi 536, 536
:c0 536, 536
:rn 536
:rd 536, 536, 0
:rdi 536, 536
:c0 536, 536
:rn 536
:rd 536, 536, 0
:rdi 536, 536
:c0 536, 536
:rn 536
:rch 536, 536
:rd 914, 1072, 0
:rdi 536, 536
:c 536, 536, 1072
:rdi 536, 378
BSSL:_run_until: closed
BSSL:_wait_for_handshake: failed
BSSL:Couldn't connect. Error = 'Certificate is expired or not yet valid.'
Is there a doc about those weird SSL logs?
The server port is 4001
BSSL:Couldn't connect. Error = 'Certificate is expired or not yet valid.'
Have you enabled NTP and set the system time? The date/time of certs are verified as well as their signing chains.
See the BSSL_Validation example which shows a failure before time is set followed by a success immediately after setting the time using the same certificate.
I'm using WiFiManager and often the captive portal closes out while it's being used. I don't think it's a WM issue but maybe more of a system troubleshooting exercise. Do phones and other devices send out multiple background requests that would interfere with the captive portal redirect?
Does anyone know why a string concat by doing page += pitem would sometimes be skipped? I have a sequential order of things that get added to page and randomly this one += addition gets skipped! I even do a Serial.println(pitem.length()) to ensure that it's not empty. It just randomly skips it sometimes!
pitem = getParameters(FPSTR(HTTP_CONFIG_HTML), useDefaults);
page += pitem; //this sometimes gets skipped!!!!!
page += FPSTR(HTTP_FORM_END);
page += FPSTR(HTTP_BACKBTN);
page += FPSTR(HTTP_END);