Problem with double-reset after flashing

RE: Problem with double-reset after flashing

Ray Breslin — Thu, 30 Mar 2017 14:55:22 GMT

Oh my god... there you pinned the problem regarding this minor issue! After checking the paths of both examples from where I ran "make flash", I could easily see it... one was "examples\peripheral\blinky\pca10040\s132\armgcc>" while the other one was "examples\peripheral\uart\pca10040\blank\armgcc>" - thanks for that!

At least now just the initial problem with the double-reset remains, but as I said before it is tolerable for now...

RE: Problem with double-reset after flashing

Hung Bui — Thu, 30 Mar 2017 14:36:39 GMT

There are 2 flavor for blinky example, one as "blank" and the other one is "s132".

The "S132" is to use when softdevice is flashed. It doesn't use any softdevice feature though, just a show case how to have an application when softdevice is flashed.

RE: Problem with double-reset after flashing

Ray Breslin — Thu, 30 Mar 2017 12:41:49 GMT

Ah ok that seems to be the problem then, but why would there be a difference in these 2 examples taken from the /examples/peripheral/-directory?

Havent modified anything in the code and just removed some obsolete paths in the Makefile (as there seem to be plenty throughout all examples).

RE: Problem with double-reset after flashing

Hung Bui — Thu, 30 Mar 2017 12:27:37 GMT

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

RE: Problem with double-reset after flashing

Ray Breslin — Wed, 29 Mar 2017 16:05:52 GMT

Oh sorry that was an accident! I edited my answer above and exchanged the 2 files and those shouldnt be identical (at least not in size - 16KB vs. 27 KB). Hopefully you can work with those!

RE: Problem with double-reset after flashing

Hung Bui — Thu, 23 Mar 2017 12:21:01 GMT

@Ray: Please double check, the 2 files are identical. And let me know which softdevice version you used.

RE: Problem with double-reset after flashing

Ray Breslin — Wed, 22 Mar 2017 17:04:35 GMT

Yes indeed it does! I edited my previous answer and attached the 2 hex-files there. Hopefully that is going to bring some insights, even though the actual cause of the double-reset would be of more interest. In the next few days I will update the J-Link-Firmware on the other pc that has no double-reset so far, just to make sure that this is excluded as potential cause.

RE: Problem with double-reset after flashing

Hung Bui — Wed, 22 Mar 2017 08:58:17 GMT

It sounds very strange, could you give me the 2 hex files you used ? We can do a hex dump and compare what inside the chip after flashing in 2 different orders.

RE: Problem with double-reset after flashing

Ray Breslin — Tue, 21 Mar 2017 16:26:49 GMT

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

RE: Problem with double-reset after flashing

Hung Bui — Wed, 15 Mar 2017 08:34:37 GMT

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

RE: Problem with double-reset after flashing

Ray Breslin — Tue, 14 Mar 2017 15:59:30 GMT

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

RE: Problem with double-reset after flashing

Ray Breslin — Mon, 13 Mar 2017 13:38:41 GMT

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!

RE: Problem with double-reset after flashing

Hung Bui — Mon, 13 Mar 2017 12:01:35 GMT

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.