Custom Device always boots into DfuTarg Mode and cannot load program.

[BendaEng]

Hi, 

I am using SDK 15.2 and Softdevice S132 6.1.1. I'm having an issue getting my custom hardware built around the Laird BL652 (nRF52832) to start the program. It always boots into DfuTarg mode. The first version of hardware we built doesn't have any issues loading both the bootloader (based on the Buttonless Bootloader) and the program, executing the program as well as perform an OTA DFU update via NRFConnect. 

The new hardware however will only boot into DfuTarg mode. We didn't change any clock settings between the hardware revisions and from what I can tell no changes were made to the connections on the Laird BL652 (nRF52832). I was searching around and found that the only way to enter DFU mode is through the following four ways: 

"

• Entering DFU mode is triggered by one of the optional sources:
  • Button (NRF_BL_DFU_ENTER_METHOD_BUTTON),
  • Pin reset (NRF_BL_DFU_ENTER_METHOD_PINRESET),
  • Special value in GPREGRET register (NRF_BL_DFU_ENTER_METHOD_GPREGRET),
  • Request from the application written to the settings page (NRF_BL_DFU_ENTER_METHOD_BUTTONLESS).

When the DFU mode is entered, the inactivity timer is started. On timer expiration, the bootloader resets. The inactivity timer is restarted on any DFU activity. The inactivity timeout is by default set to NRF_BL_DFU_INACTIVITY_TIMEOUT_MS. If the DFU mode is entered after the SoftDevice activation, then the timeout is set to NRF_BL_DFU_CONTINUATION_TIMEOUT_MS. 

"

I do not have any of the NRF_BL_DFU_ENTER settings in my sdk_config.h settings file. Based on the fact that my software + bootloader program works fine in the first version of our hardware but not the second, I'm under the assumptions that somehow a pin reset is causing the permanent DfuTarg entry. Does this seem likely? If so, where can I located the settings which would determine which pin would be causing the reset so we can change it? Is the NRF_CONFIG macro involved? If so, how do I work with that? I haven't found much documentation on it other than the following:

If that doesn't seem likely, what would some other causes of this be? 

Thanks for the help!

[Vidar Berg]

Hi,

Is it possible to attach a debugger to the custom board then start a debug session with the bootloader project to see what condition is causing it to stay in DFU mode? E.g., see if any of the checks in nrf_bootloader.c->dfu_enter_check() returns 'true'. Maybe there's a CRC mismatch that makes the nrf_dfu_app_is_valid() check fail.

[BendaEng]

Hi Vidar,

Thanks for the reply! We did do some testing in a debug session with a BL652 (nRF52832) dev kit with our second custom board and didn't find anything out of the norm compared to our first custom board.

However, we did some circuit review and found that in our first custom board we used a NMOS transistor to reset the BL652 (pin 7, nReset) (other MCU operates at 5v, BL652 at 3.3v) but in this new board we accidentally changed it to a PMOS but didn't change the circuit source or drain. We removed both of these on both versions of the boards and also held the states of the reset pin to known logic levels and it didn't change the behavior.

This led us to believe that the Laird Board BL652 had some internal problems (clock, power management, etc) which were causing the reset. After changing the BL652 module out, it solved the problem. So, long story short, it was a bad BL652. But we also found a small circuit error in the process. 

Thanks for offering a suggestion to try!