Application and development of Bluetooth single chip in vehicle infotainment equipment

Bluecore from CSR, the leading chip manufacturer of Bluetooth single chip, is the most commonly used Bluetooth single chip series. It is widely used in Bluetooth headsets, Bluetooth mobile phones and hands-free devices, and is also the first choice of many Bluetooth engineers. The author uses Bluecore5-MM (hereinafter referred to as BC5) and Freescale's Coldfire architecture 32-bit processor MCF5251 to develop an in-vehicle infotainment device that integrates USB music playback, iPOD control, Bluetooth hands-free and streaming music playback. Below, first briefly introduce the hardware structure of the device, and then explain in detail the problems encountered in the development and their solutions from the perspectives of the device software structure, BC5 software development method, memory and DSP development.

Hardware Structure

Figure 1 is a hardware structure diagram of the in-vehicle entertainment device, including power management, audio input and output and sound source management, processor and its peripheral circuits, USB interface and its power supply protection, CAN interface and other parts.

Figure 1 Hardware structure of in-vehicle entertainment equipment

As shown in Figure 1, the system adopts a dual-processor structure design of BC5-MM + 32-bit external embedded processor, and the Bluetooth part is implemented by BC5-MM. The following first introduces the key features of the chip, and then introduces the circuit design of its RF subsystem. Its chip features are as follows:

(1) The single-chip integrates the RF and baseband control of the Bluetooth system, a RISC-structured 16-bit MCU, and a Kalimba DSP with a performance of up to 64MIPS. The MCU implements the Bluetooth protocol stack and application software, while the DSP is used to implement audio and voice processing as well as the encoding and decoding of streaming music files.

(2) It has an independent audio input and output system.

(3) The wireless transmission power reaches +8dBm, and the receiving sensitivity is -90dBm. No external amplifier is required. Only a printed circuit board antenna is needed to meet the requirements of Bluetooth RF specification Class 2. The communication distance can reach 10m.

(4) It has multiple interfaces such as USB, I2C, SPI, and UART, and can be connected to an external host controller to realize complex applications. Among them, BC5-MM and the main processor communicate through UART, and the SPI interface is used for debugging and downloading BC5-MM programs and setting key PSKEY attributes.

The design of Bluetooth RF subsystem is shown in Figure 2. Since BC5-MM integrates Bluetooth RF and baseband control, the RF subsystem design can be realized by only connecting external filters and PCB antennas. The filter uses the Bluetooth balanced filter DBF81F04 with low insertion loss and high attenuation characteristics to ensure the reliability of Bluetooth communication; the PCB antenna adopts an F-type antenna, and the feedback point position needs to be determined according to the frequency center point of Bluetooth 2.4GHz. In addition, in the design of the audio input and output system, it should be noted that the audio input has a maximum voltage requirement, so when designing the peripheral microphone input circuit, it is necessary to pay attention to the selection of circuit amplification parameters to control the input voltage.

Figure 2 RF subsystem circuit diagram

Software Development

Figure 3 shows the software structure of the dual-processor in-vehicle infotainment device. The software design of the MCF5251 end is not repeated here. The BC5 software includes four parts: firmware, operating system, profile, and application. The function of the firmware is to connect to the hardware and provide the implementation of the underlying driver, including the Bluetooth underlying protocol stack and various on-chip peripherals, such as interfaces of IO, UART, Timer, ADC, etc. The operating system Virtual Machine (VM) completes the memory management, task scheduling, and message processing functions; the function of the profile is to define the functions that a certain type of device should include and its standard implementation method to ensure interoperability between devices. The application is developed on a series of APIs provided by the profile and VM, defining tasks and corresponding messages. Under the control of the VM, the message queue mechanism is used to send messages asynchronously for communication. The software development environment is Roadtunes-SDK. The SDK provides a complete Bluetooth protocol stack and source code for various profiles, and provides software solutions for in-vehicle applications. The following describes the connection management and memory issues and key technologies in DSP development.

Figure 3: On-board equipment software structure diagram

Connection Management

The in-vehicle infotainment device designed by the author needs to realize hands-free calling, phonebook downloading, streaming music playback and music remote control applications. Each application is carried out in the corresponding profile agreement based on the corresponding connection. Among them, hands-free corresponds to the HFP profile, phonebook downloading corresponds to PBAP, streaming music playback corresponds to A2DP, and music remote control corresponds to AVRCP. It is very important to manage these connections properly. First, the connections are classified. HFP and A2DP are the main connections, PBAP is the subsidiary connection of HFP, and AVRCP is the subsidiary connection of A2DP. When the mobile phone and the device establish a hands-free connection, the device actively establishes a PBAP connection with the mobile phone, downloads the phonebook and sends it to the main processor for parsing through UART. When the mobile phone and the device establish a streaming connection, the device actively establishes an AVRCP connection with the mobile phone to realize the remote control of streaming music.

[page]

The system is completely logical, but it is found that there is a high possibility of freezing at this time. After analysis, after each connection is established, both devices need to exchange link monitoring timeout, low power settings, LMP version information, supported features and other information, which consumes a considerable amount of memory in a short period of time. PBAP phone book download and UART transmission also consume a considerable amount of memory, which makes BC5 unable to allocate memory for the corresponding Bluetooth messages. Because the various behaviors of Bluetooth devices have corresponding message sequences and orders, once a link in the middle is lost, the subsequent behaviors are also uncontrollable, and continuing to run will cause program disorder. At this time, reset is a necessary choice.

The MCU memory of BC5 is 48KB, which is shared by the current ring buffers and protocol stack specific operations, profiles and applications allocated for voice or data. Therefore, it is necessary to carefully design the software development and sacrifice a certain speed performance to ensure that the program will not fail to run due to insufficient memory.

The design of a reasonable connection management scheme is as follows: initiate the establishment of an AVRCP connection 5s after the A2DP connection is completed, initiate the establishment of a PBAP connection 10s after the HFP connection is completed, and ensure that there are no two ongoing connections, that is, if the AVRCP connection has not been established, when the PBAP establishment time arrives, the PBAP connection is delayed for 10s, and the phone book is not downloaded immediately when the PBAP connection is just established, which requires a lot of memory. This solves the problem.

DSP Development

BC5 has a built-in DSP with a performance of up to 64MIPS, which can complete two major functions, namely echo cancellation and decoding of streaming music files, in software. CSR provides CVC for echo cancellation and noise suppression for the BC5 DSP, and provides SBC and MP3 codec implementation, which greatly facilitates the implementation of hands-free calling and streaming music playback functions of in-vehicle infotainment equipment. At the same time, the in-vehicle infotainment equipment designed by the author needs to have a self-diagnosis function for the audio system, requiring the generation of a standard 1kHz sound signal and the detection of the microphone. This part of the function is implemented on the BC5 DSP. The following first briefly introduces the characteristics and development methods of DSP, and then introduces the implementation of microphone detection in the self-diagnosis function.

CSR defines Kalimba, a class assembly development language for its DSP, and provides many useful operators that can be directly called by developers to implement custom functions. The DSP only has PIO interfaces with peripherals. It cannot directly interface with UART, USB, CODEC or Bluetooth data link interfaces, and needs to work with the MCU to complete specific applications. The MCU and DSP interact with each other in the form of messages based on interrupts. The message data is sent and received using the shared memory of the DSP and MCU. Both the MCU and DSP have corresponding mechanisms for sending and receiving messages.

Microphone detection requires sampling and processing of the generated sound signal. First, the MCU sets the sampling rate and gain of the microphone ADC, and sets the connection between the ADC data stream and the DSP input port. The DSP performs FFT operation on the input ADC data, and then sends the operation result to the MCU in the form of a long message for subsequent processing in the MCU. The MCU setting code is as follows:

/*VM_PCM_INTERNAL_A means left adc and left dac*/

PcmRateAndRoute(0,PCM_NO_SYNC,8000,8000,VM_PCM_INTERNAL_A);

/* Set the gains on the codec */

CodecSetInputGainA(13);

/* plug Left ADC into port 0 */

StreamConnect(StreamPcmSource(0),StreamKalimbaSink(0));

StreamKalimbaSink(0) is the input port of DSP. It is a first-in-first-out circular buffer. Kaimba provides operators to operate it, including reading data, writing data, querying remaining space and current valid data space. Before operating it, it is necessary to query the remaining space and query the current valid data space to ensure the continuity of the input data in the time domain. After the operation, the read and write pointers must be updated to ensure the correctness of subsequent operations.

The real part of the input of the FFT operation is the microphone sampling data, and the imaginary part is zero. It is a placeholder operation, that is, the output of the operation result occupies the address space of the input data. According to the FFT principle, when the input is in order, the output is in reverse order, and when the input is in reverse order, the output is in order. This reverse algorithm depends on the number of points in the FFT operation. Here, 128 points are selected for operation. According to the Fourier transform principle, the frequency resolution depends on the number of operation points and the sampling rate of the ADC. The calculation formula is as follows:

Δf=fs/N=8000/128=62.5Hz

The reverse sequence is 0 64 32 96 16 80 48 112 8 72 40 104 24 88 56 120 4...

In order to ensure the correctness of the operation, multiple operations are required. First, a timer is set to refresh the real data of the FFT input in real time. Secondly, the imaginary part is cleared to zero before each FFT operation, and the real data that has not been assigned is cleared to zero. The timer period is determined by the sampling rate and number of operation points of the ADC. Since the zero padding operation of the FFT input data will not affect the operation result and frequency resolution, the timer period is set to 14ms here so that the input data will not overflow.

After the operation is completed, it is necessary to perform a modulo operation on the real part and the imaginary part, and output them in the reverse order above to determine whether the peak value appears at 1kHz, that is, the 56th point. If so, the microphone is working properly, otherwise it is not working properly.

Conclusion

The author uses BC5 and MCF5251 to design and implement an in-vehicle infotainment device, which runs stably and reliably and has high practical value. This article discusses the application development experience and key technologies of BC5, which will help Bluetooth engineers who use BC5 for development to deepen their understanding of its design and development.