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.
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?
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.
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.
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.
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.
Hi,
Everything below 0x27000 in flash is the SoftDevice, which is Nordic's BLE stack. This is binary only so you will not see anything useful by inspecting this part with a debugger.
It would be interesting to know if the issue you see is related to it not being the first time the firmware runs (for instance because it corrupts it's own flash or something else), or if it is related to using a debugger or not. Could you try do do a full chip erase, then program the device using for instance nrfjprog but take care not to reset. Then power-cycle the device and see if it comes up normally or not? If it does, then this is probably related to difference between first run or not. If it does not come up, then perhaps it is related to the debugger being connected or not. In that case it would be interesting to see if you can recover also by attaching a debugger and starting to debug without programming again first?
Lastly, It would be interesting to see your changes to the project. Perhaps you can share a diff showing all your changes?
Okay, so this got me to a position where the problem is fixed.However, I'm still not entirely sure what happened in the first place. Does the blinky example hex use a different SoftDevice? Ultimately, my fix was to just erase the chip and then reinstall SoftDevice 140 + the application. That 64 bytes being overwritten in that section (0xE200) doesn't seem to actually cause any issues (obviously we need to change the location of flash to write those 64 bytes at some point), because I didn't change the location of that flash write but it works fine now.
At any rate, thank you for your help!
Hi,
The Blinky example in the SDK does not use the SoftDevice at all. Did you confirm that you used the Blinky example, or did you just see LED's blinking (which could be caused by any firmware)?
Another possible possible reason for recovering with a full chip erase is for instance if you programmed a bootloader in the first run. The bootloader would then blink a LED to indicate it is advertising. And if you flashed an application but did not update the bootloader settings, the bootloader would see it as an invalid application and not start it. By doing a full chip erase you would erase the bootloader. I am not sure this is what happened as I have not seen clearly if you were using a bootloader or not. But it is a possible explanation.
