Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

NRF52840 issue getting from bootloader to application

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:

  1. 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.
  2. 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.

  • Interesting piece of information... Originally I had the sdk_config.h values NRF_LOG_BACKEND_RTT_ENABLED set to 0 and the NRF_LOG_BACKEND_UART_ENABLED set to 1 which would allow me to see the output during the bootloader process. This was when I was getting the pause right before the nrf_dfu_mbr_irq_forward_address_set() function. Trying to test some things out, I turned off the NRF_LOG_BACKEND_UART_ENABLED and it now appears to be working as expected (when powered on/reset, it begins the blinky application, and when the Button 4 is held while reset it goes into DFU mode). Now I can't look at debug messages in the bootloader though.

    This is good, however, I am apparently misunderstanding the proper way to look at debug messages in the bootloader. If someone can explain to me why having NRF_LOG_BACKEND_UART_ENABLED set to 1 gives the originally questioned behavior, that would help me feel more confident in this whole process and I'd be very thankful.

  • Hello,

    What bootloader project did you start with before you started modifying it? Can you please share the path to your makefile (relative from the top SDK folder). 

    Did you try to set NRF_LOG_BACKEND_RTT_ENABLED instead of the UART? Does it behave the same, or does it work with RTT, only not with UART?

    When you compile your bootloader. What does the bootloader .hex file look like? What I really want to know is how large it is. Try to drag-n-drop it into the nRF Connect for Desktop -> Programmer application, and hover your mouse over the  Bootloader section (on top). What addresses does it occupy? 

    For comparison, this is what it looks like on the unmodified SDK17.1.0\examples\dfu\secure_bootloader\pca10056_uart\armgcc:

    You can see that it occupies the addresses: 0x000F8000 - 0x000FD81F

    What addresses does your occupy?

    Best regards,

    Edvin

  • Hi Edvin,

    Thanks for getting back to me.

    Can you please share the path to your makefile (relative from the top SDK folder).

    The path to the bootloader makefile project is:

    <SDK_15_0_Root>/examples/dfu/open_bootloader/pca10056_usb_debug/armgcc/

    Did you try to set NRF_LOG_BACKEND_RTT_ENABLED instead of the UART? Does it behave the same, or does it work with RTT, only not with UART?

    I have tried this and I am able to get output via the JLinkRTTViewer tool without any breaking like I saw when I was using the UART. I am running into a problem I think related to this post, but otherwise, RTT is working fine.

    When you compile your bootloader. What does the bootloader .hex file look like?

    Here is a corresponding image of when I drag the bootloader.hex file into the programmer tool:

    This is not at all what I would have expected. The bootloader application is split into two regions:

    Lower Region: 0x000E0000 - 0x000EDEAF 

    Upper Region: 0x10001014 - 0x1000101B

    I usually try to perform all of my uploading using the nrfjprog tool, so I have not looked at this screen yet, nor have I explicitly looked at any memory regions in any files before. This seems a little concerning in comparison to the screenshot which you posted. What would have caused this large discrepancy?

    To be honest, I am very new to the idea of memory region manipulation and linker scripts, so if you have any good resources on where to learn this, that would be very helpful!

    Thanks again for your response!

  • jspear said:
    I usually try to perform all of my uploading using the nrfjprog tool, so I have not looked at this screen yet,

    Me too, but it is a simple way to see the application size. I just wanted to check that there was enough pages that were free above the bootloader. You need two pages (0x000FE000 and 0x000FF000), and that is fine in this case. I was not sure whether you used a _debug project or a non- _debug project. The difference is that the _debug projects are moved a bit down, to give space to the logging module. 

    Since the bootloader is close to the "top" of the flash, it needs to "grow downwards", i.e. move the start address as the bootloader becomes bigger, unlike a normal application that starts at the bottom, and can grow quite a lot upwards before it starts being an issue. 

    That is all I wanted to see. the memory regions are not the issue here.

    Further investigation:

    Are you using a custom board or a DK to reproduce this issue?

    I see you are using SDK15.0.0. I don't think there are any known issues on that version.

    Can you please show me how you generate your bootloader settings, and how you generate and upload your dfu package, if you get that far?

    Is there some way for me to reproduce what you are seeing on an nRF52840DK? Is it possible to zip a project folder that I can unzip in an unmodified SDK15.0.0 to see the same behavior that you see?

    Best regards,

    Edvin

  • Since the bootloader is close to the "top" of the flash, it needs to "grow downwards", i.e. move the start address as the bootloader becomes bigger

    Is this typically something that is taken into account with each projects Makefile and Linker Script?

    Are you using a custom board or a DK to reproduce this issue?

    I am currently using the DK at the moment. We are going to be moving this over to a custom board eventually, but wanted to start simple with the DK.

    Can you please show me how you generate your bootloader settings, and how you generate and upload your dfu package, if you get that far?

    To generate my bootloader settings, I use the following command:

    nrfutil nrf5sdk-tools settings generate --family NRF52840 --application _build/nrf52840_xxaa.hex --bootloader-version 0 --bl-settings-version 1 --application-version 3 bootloader_settings.hex

    This is the BLE blinky application from the <SDK_15_0_Root>/examples/ble_peripheral/ble_app_blinky/pca10056/s140/armgcc/ project directory. 

    In terms of the dfu package, I am still working on getting kinks worked out with this, as I have an issue open here. I'm having problems uploading .zip examples via the nrfutil dfu procedure, so I haven't actually been able to test that feature yet unfortunately (though it is of high importance that I get it working soon). 

    Is there some way for me to reproduce what you are seeing on an nRF52840DK?

    I can definitely send over a .zip file. What files would be most helpful? Do you want my entire bootloader project from <SDK_15_0_Root>/examples/dfu/open_bootloader/ which includes the main.c file, or do you just want the .hex file located in the _build directory? Same question for the BLE blinky app from <SDK_15_0_Root>/examples/ble_peripheral/ble_app_blinky/ .

    Joseph

Related