getTemparature() causes system crash and prevents saving of configuration

[ahanin]

While saving configuration the program would crash with following stacktrace:

Exception (9):
epc1=0x40105a6d epc2=0x00000000 epc3=0x00000000 excvaddr=0xffffffff depc=0x00000000

ctx: sys 
sp: 3ffffdb0 end: 3fffffb0 offset: 01a0

>>>stack>>>
3fffff50:  00000056 00000001 401051ee 3ffee030  
3fffff60:  4021cdbd 3ffee8e8 00000001 00000000  
3fffff70:  402183eb 00000004 00000000 00000000  
3fffff80:  3fff1cdc 40217de2 3fffdab0 00000000  
3fffff90:  3fffdcc0 3ffe9f60 00000000 4022fd4a  
3fffffa0:  3ffe9f60 40000f49 3fffdab0 40000f49  
<<<stack<<<

This translates to:

Exception 9: LoadStoreAlignmentCause: Load or store to an unaligned address

0x40105a6d: ets_timer_disarm at ?? line ?
0x401051ee: lmacTxFrame at ?? line ?
0x4021cdbd: ieee80211_getmgtframe at ?? line ?
0x402183eb: ppCheckTxIdle at ?? line ?
0x40217de2: ppPeocessRxPktHdr at ?? line ?
0x4022fd4a: wifi_set_status_led_output_level at ?? line ?

The error causes the board to reset and configuration is not saved. I observed it only in combination with WiFi functionality.

I use Amica ESP8266 NodeMCU 1.0 board connected via USB without a temperature probe or any other devices connected. The stacktrace varies, but it always happens in ets_timer_disarm routine. I looked at what is running in timer, and it was the flash function calling getTemperature() amongst the others. And there there is a delay(200). I am not sure about the reason for this delay. Perhaps a minimal waiting time before DS boots up. But if I remove it completely or reduce to 100ms, the error is not being reproduced and configuration is changed.

I understand that I don't use D1 mini, but they are the same chip. Also, I don't have temperature probe connected which probably causes the problem. But apparently there is an unfortunate combination of events that causes that and prevents from tinkering around with the code.

Proposed pull request: #49

Upd.: I'm reading the internet on those delays now, and it seems to me that those may actually be required for assuring a certain state of peripherals. Perhaps some sort of a small state machine could be an option instead of explicit delay.

[universam1]

Install the Ds18b20 and it will work. It's not intended to be used half set up

[ahanin]

@universam1 I understand. But as for me, I don't really bother about exact temperature in the FV. Wouldn't that make sense to make the measurement of temperature value optional? Anyway, do you have an idea what is the main cause why this is happening and could you please elaborate on the purpose of those delays?

[universam1]

It makes no sense to use it without temperature information as the new firmware is also going to compensate water anomalies by temperature which becomes a hard dependency.
The delays are there to recover on an event of a non responding onewire sensor, so this is an exceptional situation.
The crash happens because this is called by the ticker calls that run kind of async to the main loop. Therefore a race condition can happen if it takes to long before called again. Lowering this might help but does not tackle your initial problem

[ahanin]

If I monitor my temperature outside and it's steady I can easily remove it from the equation, or?

Anyway, I connected the DS18B20, and now I have another problem. I get random error (codes 0 and 28) and also the watch-dogs kicks while mounting filesystem or storing configuration. I guess it is a different problem and I will have to investigate further and create another issue.

I guess the reasoning behind putting all logic to setup() is to mimic some kind of loopless one-off runs between [deep] sleeps. And use of delay() and yield() is supposed to reset wrt?