Hi,
I'm using nrfjprog with nRF52, SDK13 & S132 soft device.
I do not use mergehex during my development cycle: I flashed S132 hex once, and only reflash my application using the following command:
nrfjprog -f nrf52 --sectorerase --program application.hex
I experienced random crashes at startup: one build always crashes, but adding/removing a couple of harmless calls such as NRF_LOG_INFO("") used to be a dirty workaround.
I spent of couple trying to find the root cause, and I found that the .data segment was corrupted in RAM. For example, nrf_log_backend_serial.c:m_uart.p_uarte instance got a wrong address that led to generate a random TXD pin number, which in turn triggered a hard fault.
Breaking as early as on SystemInit showed that the instance pointer as zeroed. Looking at the source (.data section stored in the flash device at the end of the .text section) showed the same issue: most of the valid data from the ELF and .hex files where zeroed, with some spurious non-zero values showing up. This is usually a sign of write-over-non erased flash pages.
Forcing a flash page erase (before flashing the app) with the following command:
nrfjprog -f nrf52 --erasepage 0x20000-0x30000
actually fixed the problem.
The random, build-dependent, crashes were likely due to the last erased or non-erased flash page.
I'm wondering if I do not use nrfjprog the way it was expected to be i.e. --program --sectorerase should be replaced with a stronger --chiperase and softdevice be re-flashed every time, or if there is an issue with this tool (or the version of this tool, see below).
Thanks.
nrfjprog version: 9.4.0
JLinkARM.dll version: 6.16b
macOS Darwin 16.6.0 Darwin Kernel Version 16.6.0: root:xnu-3789.60.24~6/RELEASE_X86_64
