nrf/samples/nrf_rpc/protocols_serialization/server with UART Transport disables nRF9160 external flash on nRF9160DK

[Burt]

Hi,

AI says this is a known issue, but I want a much stronger explanation of why this scenario breaks. I run the server program on the nRF52840. I understand that it is necessary for the board.c program to run because the nRF52840 is the board controller. But you see, we do not have similar problems with zephyr/samples/bluetooth/hci_uart. And that uses the same UART interface between nRF52840 and nRF9160. And it appears that the zephyr/boards/nordic/nrf9160dk are designed to run board.c automatically. So how is it that the nrf_rpc sample breaks the design? Please give me a much more thorough and accurate picture than I can get from AI. Thanks.

Burt Silverman

[Susheel Nuguru]

This server sample does not list nrf9160dk/nrf52840 in platform_allow and ships no overlay for it. If you are building it for that target, you are forcing it, and your forced overlay is what kills the flash, not the RPC code. 

Flash mux = nRF52840 P0.19 board.c (external_flash_pins_routing) drives it high in board_early_init_hook + board_late_init_hook, but both hooks are Kconfig-gated on that DT node existing and being okay (zephyr/boards/nordic/nrf9160dk/Kconfig). Drop the node, set it disabled, or pinctrl-claim P0.19 , flash HOLD floats, chip seems to become non responsive.
Try these in your overlay file.

Disable (keeps node, drives P0.19 low at late init):

&external_flash_pins_routing {
    status = "disabled";
};

Delete (node ceases to exist, both hooks skip it):

/ {
    board-control {
        /delete-node/ switch-ext-mem-ctrl;
    };
};

hci_uart doesn't break it because its nrf9160dk_nrf52840 overlay is two includes, nrf9160dk_nrf52840_reset_on_if5.dtsi + nrf9160dk_uart1_on_if0_3.dtsi. Neither touches P0.19 or the flash node. I think no in-tree sample does "rpc_host on 52840 + BLE app on 9160 over UART. Maybe the community here can help if someone has managed to make it work.