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

[Burt]

It seems like the nrf/samples/bluetooth/rpc_host application is about 50% less bad than the nrf_rpc business, but no where near good enough. The entire business is really bizarre. Can drive somebody nuts. 

[Burt]

Okay, I see that if I run an image on the nRF9160 that is not set up as an RPC client, that image will run fine, with either flavor of RPC host (rpc_host or protocols_serialization server) on the 52840. We can focus on rpc_host -- I wasn't aware of its existence when I started experimenting with the other. I would be grateful if you could provide me with a working example of having rpc_host on the 52840, a simple BLE application on the 9160, and NRF_RPC_UART_TRANSPORT connecting the two processors. I see that somebody at NS had spent time developing NRF_RPC_UART_TRANSPORT, but I cannot find any code samples that use it, as opposed to using IPC on an nRF5340. It would be nice to have a chance to free up memory on our 9160 this way. Thank you.

Regards,

Burt

[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.

[Burt]

Thank you Susheel. I will experiment more, time permitting. I will leave the ticket open in case I have more questions.

Burt

[Burt]

I have a question. I am trying to run the protocols_serial/server on an old 0.9.0 nRF9160DK board, Part of the prj.conf is CONFIG_USE_DT_CODE_PARTITION=y. I have found that I am unable to get any debugging output on the nRF52840 UART0 unless I comment out that line. Okay, never mind, Google AI tells me to comment it out. I will continue my experimentation.