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