NRF52840 issue getting from bootloader to application

Question

Hello all, 
 Currently using an nRF52840-DK, GCC Makefile build tools including nrfjprog and nrfutil, Nordic SDK v15.0, SoftDevice s140 v6.0.0 
 I am currently trying to get a grasp on how the MBR, SoftDevice, DFU Bootloader, and Application all work together and I'm having a hard time combining some of the examples together cohesively. What I have done so far is the following: 
 
 Installed the SoftDevice (which includes the MBR) 
 Set the following debugging sdk_config.h elements for the bootloader example
 
 NRF_LOG_BACKEND_UART_ENABLED to 1 
 NRF_LOG_ENABLED to 1

NRF_LOG_DEFERRED to 1

NRF_LOG_DEFAULT_LEVEL

Installed a slightly customized open_bootloader (pca10056_usb_debug) example (I've simply added a few extra debug messages) 
 Installed the ble_app_blinky example application 
 Installed bootloader_settings generated using the nrfutil program 
 
 I am having an issue where the device gets stuck somewhere in the bootloader process. Based on some DEBUG messages that I've placed, it appears that it is having an issue in the nrf_dfu_mbr_irq_forward_address_set() function, called by the nrf_bootloader_app_start(). I am unable to get any DEBUG messages come out of the nrf_dfu_mbr_irq_forward_address_set() function, but right before this function is called is where I continue to get my last DEBUG message. The device gets here whenever it turns on from a power off/reset, and I want it to get past here and go to the blinky application which it cannot. 
 On the DK, I've got it set to where holding down Button 4 and turning the device on brings the device into DFU mode, where it gets stuck in the loop_forever() function found in nrf_bootloader.c and then I am unable to get to the application from here as well. Setting the NRF_BL_DFU_INACTIVITY_TIMEOUT_MS to 10000 will eventually cause it to exit loop_forever() and revert to the previously mentioned case, but again, not getting me to the application. 
 So I have two scenarios in which I am trying to get to the application from the bootloader: 
 
 Whenever I turn the device on/restart via reset pin it gets stuck in the nrf_bootloader_app_start(), most likely the nrf_dfu_mbr_irq_forward_address_set() function. 
 Whenever the device enters the DFU, I get stuck in the loop_forever() function and can't get to the application. 
 
 This is becoming a pretty big headache, so I appreciate any and all advice on the matter.

Edvin · Accepted Answer

jspear said: So I've followed this guide in order to install the latest nrfutil program 
 Ah, thanks for sharing. I was not aware of this. I just tried uninstalling and re-installing using "pip uninstall nrfutil" and "pip install nrfutil", and it didn't allow me to use the command "nrfutil nrf5sdk-tools ...". I will look into this later. 
 jspear said: I suppose I should ask then, which debugging methodology is better, RTT or UART? It seems that there are less issues coming from the RTT implementation, so it appears that this would be the better choice for debugging. If it's a subjective answer, what would be your recommendation? 
 It is indeed very much a subjective answer, and both have their pros and cons. 
 I actually prefer UART as long as I don't need to output too much data too fast, because UART is slower, but I can open a UART terminal, and it will remain connected as long as the DK is powered, because the UART terminal is actually connecting to the debugger, and not the nRF chip itself (on the DK at least). RTT is a bit more flaky, because I usually need to reconnect it every time after flashing. At least if I am using Segger RTT Viewer. If I am using Segger Embedded Studio, however, it will do so automatically, so if you are using SES, the RTT backend is very (!) neat. 
 Again, it depends on the situation. The UART backend actually requires some resources on the nRF. It requires a UART instance, so if you need to use your UART for something else, it is a blocker. The RTT is not a peripheral on the nRF in the same way. It is just the debugger reading some memory areas on the nRF, which doesn't affect the performance of the chip. It does require a debugger, though, which the UART strictly doesn't (if you have an external UART -> USB bridge). 
 So my go to is: 
 1: If I use Segger Embedded Studio -> RTT. 
 2: If I don't need too much output, my application doesn't use UART, and the nRF CPU is not throttled -> UART 
 3: RTT. 
 In addition, when you are working on a bootloader, remember that the pin configuration is carried over from the bootloader to the application, so when using GPIOs for UART or buttons, those will keep their configuration (input/output) in your application, unless you actively disable it before entering the application. Worth knowing for current consumption. This is something to keep in mind for UART, but not RTT, as it doesn't use any GPIOs. 
 
 jspear said: While the details behind this seem to be fairly complex, I believe I understand the general procedure going on and therefore the issue/solution, so thanks for the clarity! 
 Glad to help. Let me know if anything other nrfutil or bootloader questions pops up. (At least in the nRF5 SDK. I am still wrapping my head around the subject in the nRF Connect SDK). 
 Best regards, 
 Edvin

NRF52840 issue getting from bootloader to application

Top Replies

core_v2_widget.Hide()