• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 13 replies
  • Subscribers 63 subscribers
  • Views 4371 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 120363
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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!

Parents
  • 0

    @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 ?

  • 0 in reply to Hung Bui

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

Reply
  • 0 in reply to Hung Bui

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

Children
No Data
Related