SWO (pin 18) always high in secure bootloader

[vist]

We have vibrator connected to gpio pin 18 on the nRF52832. Controlling it works fine in the application but as soon we enter DFU the vibrator starts and it doesn't stop until DFU is finished and we reboot into the application.

I noticed that pin 18 can also be used for SWO but as long as ENABLE_SWO is not defined, I assume that the pin should work as a gpio.

#define VIB_PIN 18
#define LED_PIN 24

int main(void)
{
    uint32_t ret_val;

    nrf_gpio_cfg_output(LED_PIN);
    nrf_gpio_cfg_output(VIB_PIN);
    nrf_gpio_pin_clear(LED_PIN);
    nrf_gpio_pin_clear(VIB_PIN);
    
     // Protect MBR and bootloader code from being overwritten.
    ret_val = nrf_bootloader_flash_protect(0, MBR_SIZE, false);
    APP_ERROR_CHECK(ret_val);
    ret_val = nrf_bootloader_flash_protect(BOOTLOADER_START_ADDR, BOOTLOADER_SIZE, false);
    APP_ERROR_CHECK(ret_val);

    (void) NRF_LOG_INIT(nrf_bootloader_dfu_timer_counter_get);
    NRF_LOG_DEFAULT_BACKENDS_INIT();

    NRF_LOG_INFO("Inside main");

    ret_val = nrf_bootloader_init(dfu_observer);
    APP_ERROR_CHECK(ret_val);

    // Either there was no DFU functionality enabled in this project or the DFU module detected
    // no ongoing DFU operation and found a valid main application.
    // Boot the main application.
    nrf_bootloader_app_start();

    // Should never be reached.
    NRF_LOG_INFO("After main");
}

[Einar Thorsrud]

Hi,

The GPIO pin P0.18 (nRF52832) works as a normal GPIO as long as you have not defined ENABLE_SWO for your project. The bootloader should not touch pin 18 in any way out of the box, but I see in your code snippet that you configure it as an output and set it to 0. I suspect you should start looking there.

Without knowing anything about your HW I would think that the most natural would be to not touch pin 18 in the bootloader, so that it would be a disconnected input. In that case the state of the pin would be given by the external HW, typically a pull-up or pull-down resistor.

[vist]

Unfortunately there isn't a pull-down on the pin. I configure it as an output it and set it to 0 in the main application and that works well. Disabling the vibrator also works if I just run the bootloader directly. The issue only occurs when I perform a DFU. The strange thing is that controlling the other pins work fine. For example, the LED pin works as intended.

[Einar Thorsrud]

I see. After reset the pin will be a input for a short while before it is configured in the bootloader, and in this case the signal controlling the vibrator will be floating. In this case, the only way to make it behave predictably is to modify you HW by adding a pull resistor. That way the pin will never have an undefined state.