Vendor Specific Integration with Zephyr BLE Project

[moudi599]

This discussion is initiated to explore the integration of the Zephyr BLE project into a specific vendor's System on Chip (SoC). Our goal is to thoroughly understand the project, focusing primarily on the lower link layer, and determine how we can modify it to be compatible with our hardware.

[moudi599]

Hello @cvinayak ,

Regarding the MACRO NET_BUF_POOL_DEFINE, it indeed allocates from the pool located in the RAM section of memory. However, this is not the final location where the buffer resides before being sent, correct?

If I want to define and implement my own hardware queue in another section of memory, there shouldn't be any confusion with that MACRO, right? Could you please explain further?

Thank you!

[cvinayak]

NET_BUF_POOL_DEFINE is an interface of a data structure used by many subsystems like Bluetooth and Networking. I must say that it is necessary to implement the data structures in the read-write memory section of a microcontroller/SoC (CPU+memory+peripherals) so that data can my manipulated.

If I want to define and implement my own hardware queue in another section of memory, there shouldn't be any confusion with that MACRO, right? Could you please explain further?

Yes, the net_buf can be enqueued (copied) to another section of memory as needed by the lower layer in the SoC.

[moudi599]

Hello @cvinayak ,

I have a question regarding a scenario where the host and controller are located on separate chips. Assuming there is a connection between them, such as SPI, UART, or any similar interface for data transmission.

When the host enqueues a buffer in the cmd_tx_queue, how can the controller dequeue it, given that they do not share the same memory space?

Thank you for your assistance.

[cvinayak]

Assuming there is a connection between them, such as SPI, UART, or any similar interface for data transmission.

ok

how can the controller dequeue it

The host on one chip uses the SPI, UART or any similar interface to send data to over the transport, and the Controller on the other chip will use the SPI, UART or similar interface to receive the data and vice versa.

[moudi599]

To clarify, are you suggesting that there will be a cmd_tx_queue on the controller side only? If the host wants to enqueue a command, it must transmit the buffer via SPT, UART, or a similar interface, after which it will be added to the cmd_tx_queue. Is that correct?

[moudi599]

Hello @cvinayak ,

Could you please clarify the role of the memq utility in the project? Is it the final vendor queue in the hardware that we need to update and modify, or should we avoid making changes to it? Additionally, what is the distinction between memq and lll_adv_data, considering that you previously mentioned lll_adv_data is a vendor-specific lower link layer?

Furthermore, if we have data to send that is not advertisement-related, where is its final destination in the project that the vendor needs to update and modify?

Thank you for your assistance.

[moudi599]

hello @cvinayak ,
While im running beacon sample, im focusing this error:

[00:00:59.820,000] os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:00:59.820,000] os: Current thread: 0x41888 (unknown)
[00:00:59.925,000] os: Halting system

Any help please!
Thank you in advance.