Problem with double-reset after flashing

[Ray Breslin]

Hello,

I am trying to get to the bottom of a double-reset-problem which I am facing, whenever I flash my software-program to the nRF52832 (1 for the flashing and 1 after a short startup).

Currently I am using a Windows 8.1 machine with an Eclipse Neon2-GCC-Toolchain and the latest J-Link V614a-Firmware.

Here are some log-outputs that might help describing the situation:

a) Eclipse Neon2 (after flashing)

 nrfjprog --reset -f nrf52
 Applying system reset.
 Run.
 09:43:45 Build Finished (took 3s.451ms)

First thought was that I might have accidently given a double-reset in the Makefile itself, but as you can see there is nothing spectacular here and everything just seems fine!

b) puTTY (after Startup)

 0.000013 : UART Start!
 0.000220 : Reset code [0x00040005 | 0x00000000]
 0.344855 : BLE Stack Initialized
 0.345083 : Peer Manager Initialized
 0.345273 : MAC Address 00:AA:BB:CC:DD:EE
 ...
 0.348501 : Services initialized
 0.348753 : Advertising Initialized
 0.349128 : Reset code [0x00040005 | 0x00000000]
 
 0.000013 : UART Start!
 0.000220 : Reset code [0x00040005 | 0x00000000]
 0.249888 : BLE Stack Initialized
 0.250117 : Peer Manager Initialized
 0.250301 : MAC Address 00:AA:BB:CC:DD:EE
 ...
 0.253504 : Services initialized
 0.253762 : Advertising Initialized
 0.254141 : Reset code [0x00040005 | 0x00000000]

This is the usual output (99% of the time) that I am getting on the UART right after flashing my software. I also tried to debug the reset codes from RESETREAS- and GPREGRET-registers but that still left me clueless. Isnt RESETREAS supposed to show normally just a 1 for each of the reset reasons specified in the nRF52832 Product Spec v1.0? In addition to that, is it correct that there can never be more then 1 reset reason?

 0.000013 : UART Start!
 0.507008 : BLE Stack Initialized
 0.507762 : Peer Manager Initialized
 0.508152 : SYS-EVENT-DISPATCH 2
 268.943403 : MAC Address 00:AA:BB:CC:DD:EE

 0.000013 : UART Start!
 0.253794 : BLE Stack Initialized
 0.254021 : Peer Manager Initialized
 0.254205 : MAC Address 00:AA:BB:CC:DD:EE
 ...
 0.257392 : Services initialized
 0.257645 : Advertising Initialized
 0.258029 : Reset code [0x00040005 | 0x00000000]

This was pretty much a 1%-time output, where the 1st output shows a SYS_EVENT-dispatch 2, that stands for the event NRF_EVT_FLASH_OPERATION_SUCCESS and therefore a successful software-flash. Still I am not getting why the reset occurs here!? (The timestamp-gap can be ignored, its a calculation problem!)

The only observation that I can contribute so far is, that the new J-Link V614a-Firmware might be the source of the problem, because the same hardware showed a normal reset after flashing on a different PC with just J-Link V512g which came originally with the Nordic SDK itself. Havent tried using the older firmware-driver on the PC with a newer on the Nordic DK though, because I didnt wanted to cause any mailfunction.

Any1 got an idea?

Thanks in advance!

[Ray Breslin]

Ok I did what you suggested and here are my observations...

First I got the blinky- and the uart-example setup in Eclipse and ready for compilation. When compiling directly through a Make-Target (flash) then I am seeing precisely the same double-reset like I got from flashing my own program. In addition to that I found out something else...

Whenever I flash the uart-example over the blinky-example it get taken directly, but if I want to do it the other way around, then it only works when re-flashing the softdevice first! If I dont flash the softdevice then I basically re-flash the uart-example no matter which program I want to flash... Is that normal? (Just curious but I can live with that!)

(Edit 22.03.17: basic_blinky.hex/basic_uart.hex)

Now to the direct command-line-tests for nrfjprog:

C:\Nordic\nRF5_SDK\examples\ble_peripheral\test\pca10040\s132\armgcc>nrf
jprog --program _build/nrf52832_xxaa.hex -f nrf52 --sectorerase
Parsing hex file.
Erasing page at address 0x1F000.
Erasing page at address 0x20000.
Erasing page at address 0x21000.
Erasing page at address 0x22000.
Erasing page at address 0x23000.
Erasing page at address 0x24000.
Erasing page at address 0x25000.
Erasing page at address 0x26000.
Erasing page at address 0x27000.
Erasing page at address 0x28000.
Erasing page at address 0x29000.
Erasing page at address 0x2A000.
Erasing page at address 0x2B000.
Erasing page at address 0x2C000.
Erasing page at address 0x2D000.
Erasing page at address 0x2E000.
Erasing page at address 0x2F000.
Erasing page at address 0x30000.
Erasing page at address 0x31000.
Erasing page at address 0x32000.
Erasing page at address 0x33000.
Erasing page at address 0x34000.
Applying system reset.
Checking that the area to write is not protected.
Programing device.

C:\Nordic\nRF5_SDK\examples\ble_peripheral\test\pca10040\s132\armgcc>

And that directly gives me a "normal" startup already without an additional reset.

So if I skip the "nrfjprog --reset -f nrf52" in the Makefile then it is the way I want it, but I am unsure about causing a mailfunction that way...