Strange behavior upon device reset

[raz]

I might be missing something obvious here, but when the device is flashed (via SES), the application works correctly. When the device is power cycled or reset due to the watch dog timer, it turns into what appears to be the blinky example, which is incredibly different than the application I am testing. Is there something I am overlooking regarding the bootloader or some other piece of the puzzle?

Using the nRF52840 DK with a LoRa shield attached, for reference.

[Einar Thorsrud]

Hi,

It must be some firmware that does this. Can you explain what firmware you have on the DK? What does it do, both generally and with regarding LEDs? You mention a bootloader, is it a SDK bootloader? Any modifications? Which SDK version do you use, and which LEDs do you see which pattern on? Have you done any debugging to see what happens?

[raz]

Generally, it is this: https://github.com/FreeRTOS/Lab-Project-FreeRTOS-LoRaWAN with some modifications. When I download the firmware onto the DK it starts talking to our network server and doing what it is supposed to do. If I power cycle it, the firmware does not load back up; I have to redownload the firmware. As for the watch dog timer, if I force the condition by not "feeding the dog", the J link stays connected, but the LoRaWAN application is no longer running, and LED1 is blinking repeatedly. Only by redownloading the firmware does the application begin to run normally again, which kind of defeats the purpose of a watch dog timer.

[raz]

That repository uses SDK 15.2. Also, when I pause the debugger when it is in the blinking state, it says it is in "Unknown function at 0x000031A0," which from what I understand is a region of proprietary software, but I don't quite know much about that. I should clarify that when I power cycle it while it is running normally (by toggling the power switch), it comes back up in that same blinky-type state. I mentioned a bootloader simply because I am not sure what the difference is in the boot sequence between downloading the firmware over J-Link versus a cold start with the firmware already flashed.

[Einar Thorsrud]

Hi,

As you need to re-program the device this seems to indicate that something has changed in flash. If not, starting immediately after the initial programming and after a power-cycle (or watchdog reset) should result in the same behavior.

Have you added some code that writes to flash in this project, perhaps erasing or overwriting something by accident? You could try to simply compare by first programming but not resetting(!) and reading out the flash using "nrfjprog --memrd 0 --n 0x100000 > flash_dump.txt". Then reset the device so that your firmware runs and do the same again. Diffing the two dumps would show if there are any differences, and if there are, in which addresses. That should give a pointer on where to look next.

[raz]

Okay, so in trying to do this as accurately as possible, I seem to have uncovered something else entirely. I started off by doing Target > Erase All.

Prior to doing this, I had actually run the command you suggested. Before doing the erase all, I noticed that starting at address 0x00000000 there was quite a bit of diverse data (code? perhaps blinky?). After the erase all, it was 0xFFFFFFFF from addresses 0x00000000 to 0x00027000.

Now, after the WDT expires, it goes off into the weeds and does nothing (and yes, there is a small section of flash that is changed between the first run and the WDT resetting the system -- 64 bytes in the middle of that beginning section that were all 0xFFFFFFFF). I figured out the cause of that change in flash, but I do not think that is the cause here since the behavior is entirely different now. I'm guessing this is a bootloader issue? Perhaps you have some guidance on that front.

Thank you for your help.