interesting bug while testing new longaddr branch

[geeksville]

booted, wake cause 0 (boot count 1), reset_reason=reset
I2C device found at address 0x34
axp192 PMU found
I2C device found at address 0x3c
ssd1306 display found
done
Meshtastic swver=unset, hwver=unset
Setting random seed 1568126364
chip id detect 0x3
Detect CHIP :AXP192
OUTPUT Register 0x5f
AXP192 Begin PASS
DCDC1: ENABLE
DCDC2: ENABLE
LDO2: ENABLE
LDO3: ENABLE
DCDC3: ENABLE
Exten: ENABLE
----------------------------------------
DCDC1: ENABLE
DCDC2: ENABLE
LDO2: ENABLE
LDO3: ENABLE
DCDC3: ENABLE
Exten: ENABLE
SRC REG:0xcf
Charging enable is enable
Charging target-voltage : 0x2
 end when the charge current is lower than 10% of the set value
Charge current : 1000.00 mA
enable [0x40]val:0xdc
enable [0x41]val:0xff
enable [0x42]val:0x3b
Turning on screen
Read RTC time as 316052260 (cur millis 1538) valid=0
Connected to UBLOX GPS successfully
RadioConfig reset!
Installing AES128 key!
Loading saved preferences
Loaded saved preferences version 7
RadioConfig reset!
Installing AES128 key!
NODENUM=0x0, dbsize=5
Starting meshradio init...
Set radio: name=Default, config=3, ch=6, power=23
LORA init result 0
Screen: Started...
sending owner !2462abf84098/Unknown 4098/?98
Update DB node 0x0, rx_time=0
old user //
updating changed=1 user !2462abf84098/Unknown 4098/?98
Trigger powerFSM 8
Adding packet record for fr=0x0,to=0xff,id=59
enqueuing for send on mesh fr=0x0,to=0xff,id=59 (txGood=0,rxGood=0,rxBad=0)
showing standard frames
showing standard frames
Transition powerFSM transition=boot timeout, from=BOOT to=ON
Setting bluetooth enable=1
Pre BT: 175368 heap size
Starting bluetooth
*** Mesh service:
Starting low level send from=0x0, to=0xff, id=59, want_ack=0
assertion "h->from" failed: file "src/mesh/RadioInterface.cpp", line 123, function: size_t RadioInterface::beginSending(MeshPacket*)
abort() was called at PC 0x4010881f on core 1

Backtrace: 0x400950e4:0x3ffdbc20 0x40095315:0x3ffdbc40 0x4010881f:0x3ffdbc60 0x400d87fa:0x3ffdbc90 0x400d8b4d:0x3ffdbcb0 0x400d8f8e:0x3ffdbcd0 0x4019f5f2:0x3ffdbcf0 0x4019f5d1:0x3ffdbd10 0x400913f9:0x3ffdbd30

[geeksville]

Reopening, because the cause I suspect was not the cause based on a new report from @sensorsiot. This bug was introduced in 0.6.6ish? And when it occurs the corrupted nodenumber (nodenums should never be zero) gets stored in our saved preferences.

[geeksville]

I'll push out a quick build today with this fix.

Fix #153 - details below

Somehow nodenum was getting reset to zero (and saved to flash - which is bad because it makes the failure permanent). So I've changed nodenum selection to occur after we load the saved preferences (and we try to keep nodenum stable in that case).

I'm puzzled as to how it ever got set to zero (unless there shudder is some errant pointer that clobbered it). But next week I'm turning 4 byte nodenums back on, which will make this moot - because they will always be based on macaddr and the current process where nodes haggle with the mesh to pick a unique one-byte nodenum will be gone.