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

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:

Parents
  • 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.

Reply
  • 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.

Children
  • Thank you, Einar.

    CRC

    ^I'm sorry, what does this mean? 

    however, you can modify the bootloader to ignore the CRC and start the app regardless

    ^I probably do not want to do this. But why is it okay that we don't update the bootloader settings when we perform an OTA DFU? 

    If you are using an unmodified bootloader from SDK 14.2 you should not see this

    ^We didn't make any changes to the pins the bootloader interacted with, but we did make changes to enable encryption of the firmware by following this guide: https://devzone.nordicsemi.com/f/nordic-q-a/37260/adding-encryption-to-secure-dfu-sdk-v15 

    I am using SDK 14.2, so some of the files the guide mentions don't exist (The guide mentions making changes to two files, nrf_dfu_validation.c and nrf_dfu_req_handler.c). We do not have these files, but previous versions of the functions in these files are located in dfu_req_handling.c, so we modified dfu_req_handling.c instead.

    And when I use the following command to program in the combined bootloader, bootloader settings, and softdevice (S140 alpha), I see my LED at GPIO 17 light up: 

    nrfjprog --program bl_sd_merged.hex --chiperase --reset

    But when I use the below command (programming JUST the bootloader and bootloader settings), GPIO 17 does NOT light up: 

    nrfjprog --program bl_merged.hex --chiperase --reset

    And if I follow the line above with programming the softdevice by itself, as below, GPIO 17 lights up again:

    nrfjprog --program softdevice_s140_nrf52840_5.0.0-2.alpha.hex --reset

    This suggests that programming the softdevice and the bootloader together causes some interaction that makes GPIO 17 come on. Do you know what might be the reason? 

    I saw that BSP_QSPI_CSN_PIN is mapped to GPIO 17 in the bootloader. What is this pin / what does it do?

    Lastly, I think maybe this weird behavior is a symptom of something worse being wrong, because while OTA DFU works great if I am using a Nordic Dev Kit, it fails when I use my custom board. I have attached the logs for these OTA DFUs below. The logs suggest to follow the advice here to initialize the async SVCI interface, but we have already initialized this -- that can't be the problem. Are these 2 problems (GPIO 17 lighting up & DFU failing) related, and do you have ideas for how I can troubleshoot / fix this?

    File Name: 2021-05-12_btc_dfu-test.zip
    Parts: 1
    Size: 224 KB
    Soft Device Size: Zero KB
    Bootloader Size: Zero KB
    [Callback] Central Manager did update state to: Powered ON
    Connecting to BLE Device...
    centralManager.connect(peripheral, options: nil)
    [Callback] Central Manager did connect peripheral
    Connected to BLE Device
    Discovering services...
    peripheral.discoverServices(nil)
    Services discovered
    Starting Secure DFU...
    Connected to BLE Device
    Services discovered
    Secure DFU Service found
    Discovering characteristics in DFU Service...
    peripheral.discoverCharacteristics(nil, for: FE59)
    DFU characteristics discovered
    Enabling indications for 8EC90004-F315-4F60-9FB8-838830DAEA50...
    peripheral.setNotifyValue(true, for: 8EC90004-F315-4F60-9FB8-838830DAEA50)
    Indications enabled for 8EC90004-F315-4F60-9FB8-838830DAEA50
    Buttonless DFU indications enabled
    Application with buttonless update found
    Writing to characteristic 8EC90004-F315-4F60-9FB8-838830DAEA50...
    peripheral.writeValue(0x01, for: 8EC90004-F315-4F60-9FB8-838830DAEA50, type: .withResponse)
    Data written to 8EC90004-F315-4F60-9FB8-838830DAEA50
    Indication received from 8EC90004-F315-4F60-9FB8-838830DAEA50, value (0x):200101
    Response (Op Code = 1, Status = 1) received
    [Callback] Central Manager did disconnect peripheral
    Disconnected by the remote device
    Buttonless service not configured, see: https://devzone.nordicsemi.com/f/nordic-q-a/59881/advertising-rename-feature-not-working/243566#243566. To workaround, disable alternative advertising name.
    Connecting to BLE Device...
    centralManager.connect(peripheral, options: nil)
    Connection timeout!
    centralManager.cancelPeripheralConnection(peripheral)
    [Callback] Central Manager failed to connect to peripheral (timeout)

    2021-05-12_Nordic DK_DFU success (sharable).txt

    Something else weird: inside both of these log files, it says "Application with buttonless update found" (line 24), then "Buttonless service not configured" (line 33). These seem to contradict each other -- why?

    Below are all the logs I get in the debugger while undergoing DFU, in both the failed and successful cases:

    <info> app: Received indication state 1
    <info> app: Writing peer data to the bootloader
    <info> app: ---------------system attribute table: 8--------------
    <info> app: Device is preparing to enter bootloader mode

    <info> app: Device will enter bootloader mode

    <info> app: Power management wants to reset to DFU mode

    <info> app: Power management allowed to reset to DFU mode

    Thanks in advance for your help! 

  • Hi,

    nordev said:
    ^I'm sorry, what does this mean? 

    CRC is an acronym for Cyclic redundancy check, which is a very common approach to check for accidental changes in a set of data. It is normally used by the nRF5 SDK bootloader to check the integrity of the application (though it also support other methods).

    nordev said:
    ^I probably do not want to do this. But why is it okay that we don't update the bootloader settings when we perform an OTA DFU? 

    When you do OTA DFU, the bootloader will update the bootloader settings with the hash of the application, which is provided in the init packet in the DFU procedure. But when you just flash the application yourself this does not happen, and then you need to also update the bootloader settings page yourself by generating a new settings page and programming that.

    nordev said:
    This suggests that programming the softdevice and the bootloader together causes some interaction that makes GPIO 17 come on. Do you know what might be the reason? 

    The BSP has this pin assigned to QSPI but it is not used in the bootloader. There must be some changes in your code that use P0.17as it is not used in the example bootloader we provide, but I cannot say what without seeing your code though. Alternatively, if you have confirmed that you do not do anything with that pin then it could be worth looking at your HW.)

    nordev said:
    Are these 2 problems (GPIO 17 lighting up & DFU failing) related, and do you have ideas for how I can troubleshoot / fix this?

    Are both these issues only visible on your custom HW and not on the DK? Can you share the schematics of your custom HW?

    nordev said:
    while OTA DFU works great if I am using a Nordic Dev Kit, it fails when I use my custom board.

    Have you done any debugging in the bootloader? For instance tested the _debug version with RTT logging? If the bootloader essentially does not work at all on your custom board, a typical thing that comes to mind is if your custom board does not have the optional 32.768 kHz crystal, but you still have not changed the bootloader configuration. By default the example bootloader (and example applications) will configure the SoftDevice to start the 32.768 kHz crystal, and if that is not present, the bootloader will not work as the SoftDevice will block for ever waiting for the clock that does not exist to start.

    nordev said:
    Something else weird: inside both of these log files, it says "Application with buttonless update found" (line 24), then "Buttonless service not configured" (line 33). These seem to contradict each other -- why?

    There seems to be an issue with setting advertising name. This is useful for iOS to be able to connect to the same device again after it enters DFU mode, as iOS does have APIs involving the BLE address. This is not needed for buttonless DFU itself, but without it when using iOS you may need to search for the nRF device and connect again, as the app on the phone may not be able to do it automatically. I suggest you open a separate question for this if you want to dig further to avoid putting too much different topics in this thread, making it difficult to keep track.

    Lastly I want to mention that using SDK 14.2 with the nRF52840 is OK for playing with, but you should not use it for production. SDK 15.0.0 was the first with production support for the nRF52840. As you write that you eventually plan to upgrade I would suggest doing that immediately, as migrating can be a bit of work. It is better to migrate sooner rather than later, and then you would typically want to migrate to the latest SDK available, which for the nRF5 SDK currently is version 17.0.2.

  • HI Einar,

    Thanks sincerely for the detailed response. 

    Are both these issues only visible on your custom HW and not on the DK?

    This was a good point -- I just checked, and GPIO 17 only goes high on my custom board, not on the DK. 

    Have you done any debugging in the bootloader? For instance tested the _debug version with RTT logging? If the bootloader essentially does not work at all on your custom board, a typical thing that comes to mind is if your custom board does not have the optional 32.768 kHz crystal, but you still have not changed the bootloader configuration. By default the example bootloader (and example applications) will configure the SoftDevice to start the 32.768 kHz crystal, and if that is not present, the bootloader will not work as the SoftDevice will block for ever waiting for the clock that does not exist to start.

    This is also a great point -- I don't think the bootloader works on my custom board. When I run it on the Nordic DK it seems to work fine (nothing prints in the debugger logs though). But when I run on the custom board, pressing "play" results in it being paused immediately. It "runs" for a fraction of a second and then pauses again. 

    Where do I change the options so I don't start the crystal? 

    Thanks!

  • Hi,

    I am sorry for the late reply. You change the 32.768 kHz clock source by adjusting NRF_SDH_CLOCK_LF_SRC in the bootloader's sdk_config.h. To use internal RC, it should be set to 0. Then you should also set NRF_SDH_CLOCK_LF_RC_CTIV to 16, NRF_SDH_CLOCK_LF_RC_TEMP_CTIV to 2 and NRF_SDH_CLOCK_LF_XTAL_ACCURACY to 1.

Related