This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Stuck at DFU bootloader after flashing

Hello,

Not so long ago I asked this question and the solution I was given is still working for the devices I was using.

Now I've received a new version of the device in which the only difference is that the only LED light now has PWM. So I modified my code to take advantage of that.

Naturally I want to flash the bootloader, softdevice and firmware so I used the script I was using from my previous question. And I'm having some different issues from what I had when I asked that. I've searched through the forums and found this other question that pretty much is the same issue I'm having.

What I'm seeing is that after flashing following my script:

set TARGET_SNR=260108811

del bl_settings.hex

nrfutil settings generate --family NRF52 --application ble_app_template_pca10040_s132.hex --application-version 1 --bootloader-version 1 --bl-settings-version 1 --key-file private.key bl_settings.hex

nrfjprog -e --snr %TARGET_SNR%
nrfjprog --eraseall
nrfjprog --program s132_nrf52_7.0.1_softdevice.hex --verify --snr %TARGET_SNR%
nrfjprog --program secure_bootloader_ble_s132_pca10040.hex --verify --snr %TARGET_SNR%
nrfjprog --program ble_app_template_pca10040_s132.hex --verify --snr %TARGET_SNR%
nrfjprog --program bl_settings.hex --verify --snr %TARGET_SNR%
nrfjprog --memrd 0x100000A4 --n 8
nrfjprog --reset --snr %TARGET_SNR%

@pause


I'm stuck at the dfu bootloader since using the nrfConnect Android app I'm only seeing my device as DfuTarg.
If I connect to the dfuTarg and try to upload the firmware via dfu, the process completes but it's still stuck in the dfu bootloader.

So before going to the question I found that resembles my problem, I decided to try to flash this PWM version of my firmware to one of my old devices without the pwm module knowing that the LED light might not work. And this works fine (the light doesn't as expected), I don't see the device as DfuTarg, I see it with the custom name I give it in the firmware.

So now I'm going back to one of my newest boards with PWM. I decided to try the steps given in the comments from that question.


1. I see that the P0.21 is the reset pin, so I removed the following I had in my code. Because I see that I have CONFIG_GPIO_AS_PINRESET set in the configuration.

nrf_gpio_cfg_output(PIN_P0_21);


Doing this did not ressolve my problem.



2. This is the comment marked as a solution to the question. I couldn't find the "flash_uc.h" the answer mentions, but in the linker options of my firmware, bootloader and  what mentions the bootloader settings page I see the following addresses:

Firmware:

FLASH_START=0x26000
FLASH_SIZE=0x5a000


Bootloader:
FLASH_START=0x78000
FLASH_SIZE=0x6000


Bootloader settings page:
* Start Address:            0x0007F000


Now I see that the bootloader and the bootloader settings page are pretty close.
If I add the Bootloader start and size I end up with 0x0007E000. So I don't think these two are colliding.
But if I add the firmware start and size I end up with 0x00080000, which I think it could be overlapping the bootloader and its settings.

Is this thought process correct? How can I solve this?

Thanks,
Pau

  • Hi Pau, 

    The process looks correct. You could use the secure_bootloader_pca10040_s132_ble_debug version and check the debug info.

    Are you able to provide the debug log? Thanks. 

    -Amanda H.

  • Hello Amanda,
    Thanks for your reply.

    I'm not sure how to perform what you suggested since I've never debugged with a bootloader. Do you know any guide on how to do what you suggested?

    Even though I'm unsure how to do it. I tried the following:
    1. Successfully compiled the debug bootloader using SES.
    2. Erased everything on my board.
    3. Turned on the RTT viewer and connected the device.
    4. Ran my script changing the bootloader with the debug one and didn't flash my firmware and the bootloader settings (because as far as I know, once you perform a DFU the Bootloader settings page is created automatically)
    5. Nothing happened on the RTT viewer.
    6. Couldn't find the DfuTarg device in the nrfConnect app.
    7. So I went to nRFgo Studio to see if anything was flashed. So I clicked Refresh.
    8. At this moment the RTT viewer started printing things.
    9. So I uploaded the firmware via DFU successfully. At the end of the process the device still appears as DfuTarg.

    I'm attaching in a plain text file what I saw in the RTT screen. Is this what you asked for?

    booloader_debug_log.txt
    Edit: I see that in line 3968 it says: 00> <info> app: No firmware to activate.
    Best regards,
    Pau

  • Hi Pau, 

    I the log, we see: 00> <debug> app: DFU mode requested via button.

    Maybe you just need to disable the Configuration parameters -> NRF_BL_DFU_ENTER_METHOD_BUTTON setting in the bootloader

    Regarding the reset pin, it is important that it can be set by both the application and bootloader. This is easy to forget.

    -Amanda H.

  • Hi Amanda,

    I didn't know that setting existed. I followed Getting started with Nordic's Secure DFU bootloader, a step by step guide for my bootloader.

    NRF_BL_DFU_ENTER_METHOD_BUTTON was on so I turned it off.

    Just next to this setting there was NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN set to P0.16 which in my new board this is used for the PWM. So even though I turned the previous setting off I moved this to a free pin.

    At first this didn't work, so I started looking the following settings and found that NRF_BL_DFU_ENTER_METHOD_BUTTONLESS was off. Since my board doesn't have any buttons and I update the firmware via DFU I turned this on.

    After these two changes it started working.

    Thanks Amanda,

    Best regards,

    Pau

Related