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

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

  • I can see the uart hex has the flash located at address 0x00000 are you sure it should be used with the softdevice ? The blinky start address was at 0x1F000.

    If it wasn't made to work with softdevice then it's quite normal to explain what you saw. You flash the softdevice and blinky first, it works, normally.

    Then you flash the uart.hex and it will overwrite the softdevice and start from address 0x0000 .

    After that you flash the blinky, it won't work as the uart is still at address 0x00000

Reply
  • I can see the uart hex has the flash located at address 0x00000 are you sure it should be used with the softdevice ? The blinky start address was at 0x1F000.

    If it wasn't made to work with softdevice then it's quite normal to explain what you saw. You flash the softdevice and blinky first, it works, normally.

    Then you flash the uart.hex and it will overwrite the softdevice and start from address 0x0000 .

    After that you flash the blinky, it won't work as the uart is still at address 0x00000

Children
No Data
Related