Pin 17 goes high before application runs when bootloader in use

Hello! 

I think I have the below problem, except I am using NRF52840 and therefore PCA10056. I am using SDK14.2 and the alpha softdevice. I am aware these are out of date and eventually have plans to upgrade. 

(+) SWO (pin 18) always high in secure bootloader - Nordic Q&A - Nordic DevZone - Nordic DevZone (nordicsemi.com)

This example didn't totally help me, because I looked in the PCA10056 secure_dfu example, and there was no dfu_observers function in main.c that I could find. 

My problem; Upon every single powerup (not just during DFU), pin 17 goes high before the application even starts running. 

I can tell because I have an LED attached to pin 17. And when I use the Segger debugger to download firmware to my custom board, I notice that the LED comes on after the loading bar tells me the firmware has finished downloading to the board, but before I press the "play" button to actually run the application. Normally (e.g. when I do not have a bootloader), nothing turns on prior to the application running. 

I am also concerned there may be other pins that go high that shouldn't, but I can't tell which pins because maybe they are not attached to something obvious like an LED. But I need to know which pins in order to predict and mitigate potential issues.

 

Other item of note: I experience a "autorun + broken application" effect if I do not regenerate the bootloader settings after recompiling a new application. Details: after recompiling, if I have not regenerated bootloader settings and freshly added the settings to the device, if I then Debug > Go, the LED turns on, and there is no play button in the debugger -- just a pause button because it is already playing. The application is also entirely broken / does none of the functions it is supposed to do. I am not clear that the application runs at all, because LED blinks that are supposed to occur on startup do not occur at all. When pressing the pause button, it stops somewhere in the disassembly). Can you also explain why this is happening? 

This is the play/pause button I am talking about:

  • Hi,

    Referring to the SDK 14.2 bootloader code it configures GPIOs connected to LEDs and buttons which you can see in examples\dfu\bootloader_secure_ble\main.c 1 GPIO for buttons which is BOOTLOADER_BUTTON = BSP_BUTTON_3, which in turn is BUTTON_4 which is 25 in pca10056.h. And for LEDs, GPIO 13 to 16 is configured as outputs. No other GPIOs are used by the SDK bootloader by default.

    If you are using an unmodified bootloader from SDK 14.2 you should not see this, but you have probably made some changes to adapt to your HW, perhaps modify the board file or use another board file so that GPIO 17 is used?

    Regarding the last question about running app without updating bootloader settings that will not work, because if you modify the app without updating the bootloader settings the CRC will not match, and the bootloader will think that the app is corrupt and enter DFU mode instead of starting the app. So this is intentional behavior. however, you can modify the bootloader to ignore the CRC and start the app regardless by modifying nrf_dfu_app_is_valid() in components\libraries\bootloader\dfu\nrf_dfu_utils.c to skip the CRC check.

Related