Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

samples/bluetooth/unicast_audio_server doesn't configure heap memory for IPC #72708

Closed
yclistanford opened this issue May 14, 2024 · 5 comments
Closed
Assignees
Labels
area: Bluetooth Audio area: Bluetooth bug The issue is a bug, or the PR is fixing a bug platform: nRF Nordic nRFx priority: low Low impact/importance bug

Comments

@yclistanford
Copy link
Contributor

Describe the bug
I built the samples/bluetooth/unicast_audio_server for the nrf5340_audio_dk_nrf5340_cpuapp core/board. The sysbuild for that sample in turn builds samples/bluetooth/hci_ipc for nrf5340_audio_dk_nrf5340_cpunet core/board.

The application core and network core on the nrf5340 talk to each other using IPC RPMSG.

After flashing both images I saw that the network core allocates memory for the RPMSG virtqueue correctly (the memory allocation is done by this call to virtqueue_allocate: https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/ipc/ipc_service/lib/ipc_static_vrings.c#L117) but the application core fails this call to virtqueue_allocate.

After a little digging I found that virtqueue_allocate is backed by modules/hal/libmetal and it expects CONFIG_HEAP_MEM_POOL_SIZE > 0. I checked the .config file, the network core has CONFIG_HEAP_MEM_POOL_SIZE=8192 but the application core has CONFIG_HEAP_MEM_POOL_SIZE unconfigured (though it has CONFIG_HEAP_MEM_POOL_ADD_SIZE_BOARD=4096).

After I added CONFIG_HEAP_MEM_POOL_SIZE=8192 to samples/bluetooth/unicast_audio_server/prj.conf, the application core can initialize IPC RPMSG correctly.

It seems either samples/bluetooth/unicast_audio_server needs that configuration, or libmetal should be smarter in memory allocation?

To Reproduce
Steps to reproduce the behavior:

  1. west build -b nrf5340_audio_dk_nrf5340_cpuapp --sysbuild third_party/zephyr/samples/bluetooth/unicast_audio_server/ (I have Zephyr in third_party)
  2. west flash --recover (to get past the nrf53's APPROTECT)
  3. west flash --domain hci_ipc
  4. west flash --domain unicast_audio_server
  5. Watch the serial console for the application core and network core, add printf debugging as needed

Expected behavior
samples/bluetooth/unicast_audio_server on nrf5340_audio_dk_nrf5340_cpuapp should successfully initialize IPC.

Impact
It slowed me down significantly in getting started with the NRF5340 Audio DK.

Logs and console output
Below are UART logs from the application core, including some of my custom printf logs:

static vrings init
metal_io_init
libmetal_setup
vq_setup, vring size 308
err -12
*** Booting Zephyr OS build v3.6.0-12-g7b42d8f8f9d7 ***
[00:00:00.258,239] bt_hci_driver: IPC service instance initialization failed:2

[00:00:00.258,239] bt_hci_core: HCI driver open failed (-12)

Environment (please complete the following information):

  • OS: Linux
  • Toolchain: Zephyr SDK
  • Commit SHA or Version used: 468eb56 (tag: v3.6.0, manifest-rev) release: Zephyr v3.6.0
@yclistanford yclistanford added the bug The issue is a bug, or the PR is fixing a bug label May 14, 2024
@aescolar aescolar added the priority: low Low impact/importance bug label May 14, 2024
@Thalley
Copy link
Collaborator

Thalley commented May 16, 2024

Confirmed to be an issue. Thanks for the report

@Thalley
Copy link
Collaborator

Thalley commented May 16, 2024

Hi @yclistanford while I could reproduce an issue, it is not the same as you do.
There was an issue with IPC, but it was not related to heap, but rather some BT buffer sizes. These have been fixed by #72861.

After the above PR, I can no longer reproduce any issues given the steps in this issue. Can you try to apply the changes from #72861 to your build and see if there is still an issue?

@Thalley
Copy link
Collaborator

Thalley commented May 27, 2024

@yclistanford PLease respond, else this issue will be closed.

@yclistanford
Copy link
Contributor Author

Yes I did need the BT buffer sizes in #72861. That's a separate issue. For the heap mem pool size, the sample has CONFIG_HEAP_MEM_POOL_ADD_SIZE_BOARD=4096 and that should become K_HEAP_MEM_POOL_SIZE (calculation is in kernel/CMakeLists.txt). For some reason that did not happen for me in my previous build. I will close this issue.

@yclistanford yclistanford closed this as not planned Won't fix, can't repro, duplicate, stale May 29, 2024
@Thalley
Copy link
Collaborator

Thalley commented May 29, 2024

Yes I did need the BT buffer sizes in #72861. That's a separate issue. For the heap mem pool size, the sample has CONFIG_HEAP_MEM_POOL_ADD_SIZE_BOARD=4096 and that should become K_HEAP_MEM_POOL_SIZE (calculation is in kernel/CMakeLists.txt). For some reason that did not happen for me in my previous build. I will close this issue.

Thanks.

The CONFIG_HEAP_MEM_POOL_ADD_SIZE_BOARD is not set by the sample itself, but rather with the board. So if you encounter issues with this value, it's likely an issue with the specific board you are compiling for, rather than the sample :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Bluetooth Audio area: Bluetooth bug The issue is a bug, or the PR is fixing a bug platform: nRF Nordic nRFx priority: low Low impact/importance bug
Projects
Status: Done
Development

No branches or pull requests

4 participants