Problem with not entering serial recovery mode with nRF5340

[kudo]

Hello,

We are verifying FW changes using serial recovery on a module equipped with nRF5340.

If you use a program that changes the GPIO of the serial recovery start button and reset the GPIO for serial recovery start in the input state, the FW will start without entering recovery mode.

On the nRF5340-DK, the same code will enter recovery mode.

Please help us resolve this issue.

environment

• module：NORA-B101-00B
  • ublox nRF5340 built-in module
  • no external 32k
• Development environment：Visual Studio Code
• SDK：nRF connect SDK v2.3.0

Program used

• Created based on the sample below.
  • mcuboot_serial_recovery_uart
• Changed clock setting from external 32k to internal.
• Changed serial recovery start GPIO (0.23 -> 1.15).
• Added software reset

1464.mcuboot_serial_recovery_uart.zip

procedure

1. Write the program into a module in VScode.
2. Input H to pin 1.15.
3. A software reset of the program will be executed.
4. The program will start without entering recovery mode. (Check the print output at startup)

reference

• Can not modify GPIO number to use to enter DFU mode with MCUboot on nRF52840dk
• nrf5340 - How to make a clean software reset

[Einar Thorsrud]

Hi,

When I test this on the nRF5340 DK, recovery mode is entered when 1.15 is high, which is the same as you see from what I understand? When it comes to your custom board I am not able to test that, but I wonder if you have double checked that P1.15 is actually connected? Are you able to read both a high a and a low state on that pin on your custom board with a simple test firmware just to rule out that as an issue?

[kudo]

Hi Einar,

Einar Thorsrud said:

When I test this on the nRF5340 DK, recovery mode is entered when 1.15 is high, which is the same as you see from what I understand?

Yes, the behavior is the same.
Inputting High to P1.15 will enter recovery mode.

Einar Thorsrud said:

When it comes to your custom board I am not able to test that, but I wonder if you have double checked that P1.15 is actually connected?

Yes, we have confirmed that the custom board's FW is able to detect P1.15 using the code below based on the hello_world sample.

nrf5340dk_nrf5340_cpuapp_ns.overlay :

/ {
	buttons {
		compatible = "gpio-keys";
		bootkey: boot_key {
			gpios = <&gpio1 15 (GPIO_PULL_DOWN | GPIO_ACTIVE_HIGH)>;
			label = "boot start key";
		};
    };
	aliases {
        tp0 = &bootkey;
    };
};

&spi4{
    status = "disabled";
};

main.c:

#include <zephyr/kernel.h>
#include <zephyr/device.h>
#include <zephyr/drivers/gpio.h>
#include <zephyr/sys/printk.h>

#define SLEEP_TIME_MS	1000

#define TP0_NODE	DT_ALIAS(tp0)
#if !DT_NODE_HAS_STATUS(TP0_NODE, okay)
#error "Unsupported board: tp0 devicetree alias is not defined"
#endif
static const struct gpio_dt_spec testpin = GPIO_DT_SPEC_GET_OR(TP0_NODE, gpios,
								  {0});

void main(void)
{
	int ret;
	
	printk("Hello World! %s\n", CONFIG_BOARD);

	if (!device_is_ready(testpin.port)) {
		printk("Error: testpin device %s is not ready\n",
		       testpin.port->name);
		return;
	}

	ret = gpio_pin_configure_dt(&testpin, GPIO_INPUT);
	if (ret != 0) {
		printk("Error %d: failed to configure %s pin %d\n",
		       ret, testpin.port->name, testpin.pin);
		return;
	}

	while (1) {
		int val = gpio_pin_get_dt(&testpin);
		
		if (val > 0) {
			printk("pin high\n");
		}
		else if (val == 0) {
			printk("pin low\n");
		}
		
		k_msleep(SLEEP_TIME_MS);
	}
}

[Einar Thorsrud]

I see, that is strange. Do you use the exact same firmware on the DK as on the custom board with the NORA-B101-00B module? Meaning the exact same hex files? For such a simple sample, and with this test firmware where you have disabled the LFXO, that should work on both the board with NORA-B101-00B and the DK. If it does not, we need to look more closely at the HW and how you test to see where there could be any differences.