When playing with the NRF9160 samples (https_client and mqtt_simple, haven't tried others yet), I found a problem and workaround to that problem:
I'm not sure if it's a problem with west build or west flash, but either way the NRF9160's SPM region ends up with incorrect contents and the flashed code won't run.
Symptoms include very strange crashes in the low address range of the flash memory (bus faults, memory alignment faults, sigtraps, etc) before main() is called, and the data in the low flash address range not matching the SPM provided by west build (build/spm/zephyr/zephyr.{hex,elf}).
Remote debugging using localhost:2331
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0xeffffffe in ?? ()
(gdb) mon reset 2
Resets core & peripherals using RESET pin.
(gdb) cont
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
0xeffffffe in ?? ()
(gdb) bt
#0 0xeffffffe in ?? ()
#1 <signal handler called>
#2 0x000010c8 in ?? () ### this address seems to randomly change from time to time
#3 0xfffffffe in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
The workaround is to nrfjprog --program build/spm/zephyr/zephyr.hex --sectorerase; then jump into GDB and issue mon reset 2 and cont.
After this the code will run normally even after closing gdb, another west flash, or unplugging/replugging the DK.
This doesn't need to be done every time, but I've had to do it quite often to get things working.
I currently suspect that every time we flash code from another system (one of my colleagues has a mac) the SPM needs re-doing on both sides, but haven't yet done a sufficiently scientific test to confirm this trigger.
I'm posting this so that 1) NRF engineers can try to work out what's going on, and 2) anyone else who stumbles across this problem can try my workaround until a proper solution is published.
