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!

[Hung Bui]

Hi Ray,

Have you tried to use nrfjprog (in your commandline , not from the make file) to flash and reset ? If you try, will try see the double reset ? Is there any chance that it's reset because of the application code ? I would suggest you to test with one of our example in the SDK, try to print something at the beginning of the code.

I assume "Reset code ..." is printed twice in your application ? one after UART Start and one after Advertising Initialized ? It's a coincident that it reset right after that ?

RESETREAS is cumulative, if you don't clear it it will collect all the reset reasons happen before unless it's a power reset.

[Ray Breslin]

Hi Hung Bui,

thank you for your reply - for the double print-out of the reset-code you are absolutely correct. I did one as early as possible (directly after initializing the UART and the timer-clk) and one as late as possible, where I am basically "hanging" in the main-loop and waiting for bt-, signal- or interrupt-events.

Will try to do the nrfjprog-tests asap and get back to you with the results!

[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...

[Hung Bui]

@Ray: You did compile and flash from command line or from Eclipse ? If you try simply call "make flash" from command line do you see the same early reset ?

When you mentioned the issue when you flash ble_app_uart over ble_app_blinky , what exactly happened ? Can you try to debug to see if the program actually executed and if there is any assertion ? Which SDK you are using ?

[Ray Breslin]

@Hung Bui: Currently I am using the v12.0.0 of the Nordic SDK that I downloaded in September 2016. As for the compilation- and flashing-procedure, I normally just use a specific Make-Target in Eclipse, which you can install for a Makefile. After your suggestion I already tried "make flash" directly from the command-line and I am seeing exactly the same kind of behaviour. This is why I am assuming my observation is correct and I can simply uncomment "nrfjprog --reset -f nrf52" in my Makefile. For the "over-flashing"-problem I simply first compiled and flashed the ble_app_blinky-example, which is working just fine triggering LED1-4 and then I compiled and flashed the ble_app_uart-example, which gave me a "Start: "-prompt - waiting for keyboard-input. So this way is working! But the other way around is not, so I would guess the command-prompt is causing some kind of flash-interrupt.