nRF52840 debugger launches into DfuTarg mode

[bojennett]

I have been having nothing but problems since moving to the nRF52840 and using Segger Embedded Studio.

I have built a project that uses the soft device, my application, and the secure Bootloader (buttonless DFU).

A similar project on the nRF52832 using SDK17 has had no problems.  But all example projects (plus any project I write) on the nRF52840 has been almost IMPOSSIBLE to use the debugger.

I am using SES 5.68 downloaded from Nordic.

When I go to run the debugger, the application compiles, and I see the J-Link programmer start up to erase, program, and verify, but then when the installation is done, the device only boots up into DFU mode!!!!  I can see it advertising as DfuTarg in a bluetooth scanner, but my application never loads.  I can also confirm that the script that should run - the "TargetInterface.resetAndStop()", does not run, because, well, it isn't actually in the "main" loop of my application!

Note that every once in a while, I have had this work.  The application stops, I can then click play again to continue, and I can see the output window with all my logging on SWD showing up.

This is EXTREMELY frustrating.  Note that this is with ALL projects - not just my project.

I can take my project and take it through the entire nrfutil process to turn it into hex files and OTA, and then burn the hex file directly, and it is fine.  But I can almost consistently, 100% of the time, get it to fail if I try and run the debugger.

Any idea what is going on?  I can't do any debug, which is not acceptable.

[bojennett]

The thing that seems reproducible is this:

1) Make changes to application, compile it
2) Run the nrfutil steps to make the hex file.
3) Install the hex file via JFlashLite
4) Go back into Segger Embedded Studio, and then run the debugger

If I do that, then the latest changes I made work - I can see them in the debugger.

But if I change the application and just install it over the current application (without reflashing it manually), then it boots into the Bootloader only.

So, if I "debug" over the application I just flashed manually, I'm fine.  But if I "debug" something new over the older application, it only goes into Bootloader mode and stays there.

This feels like a tool issue.  It cannot be my application, because I can build a hex just fine (also, I can OTA over it just fine).  So the application is fine.  But there is something weird with trying to debug... something that I *never* experienced with the 52832 or the 51822,  Only started when I went to the 52840

[Hung Bui]

Hi Josesh, 

I believe it's not a bug but a feature. 
If you have a look inside dfu_enter_check() function in nrf_bootloader.c you can find the check for CRC match in app_is_valid()
This is to prevent the application to be modified unexpectedly. In your case when you flash a new application directly the bootloader will detect that as the CRC won't match and it will stay in DFUTarg mode. 
If you update the application via the bootloader instead, you wouldn't have any problem with that as the bootloader will update a new CRC matches with the new application. 
For development you can comment out the check for CRC in the bootloader , or use a flag/button or something in flash to skip the check, or generate bootloader setting to overwrite the CRC value to the correct value. 

if (!app_is_valid(crc_on_valid_app_required()))
{
NRF_LOG_DEBUG("DFU mode because app is not valid.");
return true;
}

[bojennett]

Hung Bui...

Thank you for this information.  I will look into this.  The Bootloader was delivered to us by a third party so I don't have access to that source code.  Your statement about this check rings a bell to me, though I don't actively remember doing this on my 82532 projects.  But maybe I did.  I don't know if I will be able to get this in the next couple of days, but I will look into it and let you know.