CSR8670 serial communication exception after running offline

1. UART Communication Exception 1.1. Phenomenon

Friday debugging CSR8670 encountered a serious problem: in the Xide environment debugging, CSR8670 received the data from the MCU will respond normally. Once running offline, the communication between CSR8670 and MCU is abnormal, which is as follows:

• The MCU sends an X-byte command to the Csr8670,uart task to receive a command that is less than X bytes long and the number of bytes sent first is lost
• The MCU sends multiple X-byte commands at shorter intervals to the Csr8670,uart task the first command received is less than X bytes long, and the length of each command is x bytes

1.2. Check the hardware

Let's start checking the hardware for problems:

• The waveform of TXD is measured with oscilloscope and the waveform is normal.
• Resolves the protocol for TXD, RXD transmission, and conforms to the protocol.
• Reduce the baud rate, the phenomenon still exists.
• The TXD and rxd between the CSR8670 and MCU are connected directly with the fly line, and the connection on the circuit board is disconnected, the phenomenon still exists.
• The phenomenon disappears when the software is burned to the official demo board of the CSR.

Comparing the schematic diagram of the demo board and our own circuit board, no pins were found to configure the UART function. The main difference is that the demo board with USB power supply, our own board is regulated power supply module power supply.

1.3. Check the Software

The program that is responsible for the MCU-side code Ape J recalls that the previous version of the software did not encounter this problem during testing. So the program Ape J quickly tested the previous version of the software, found a new phenomenon:

• New and older versions of the software have the same phenomenon of communication anomalies
• Once the CSR8670 is connected to the phone successfully, the UART communication is back to normal
• UART communication anomaly When CSR8670 does not establish a Bluetooth connection with other devices

1.4. Check the programmer

It seems that the old software also has the same problem, so the focus is back to figuring out why they can respond properly when debugging in a xide environment. Online debugging must be connected to the USB-SPI programmer, which does not require a connection programmer to run offline.

USB-SPI Convert:

Custom firmware, stored in flash memory, takes USB packets containing SPI commands and forwards the commands over SPI. The DSP:

• Serialises the SPI commands
• Uses the PIO pins to create the Spi_mosi, SPI_CSB and SPI_CLK signals
• Reads the Spi_miso line

USBSPI automatically reduces the SPI bit rate when it sees SPI data corruption.

Voltage level was set by default to 3.3V.

So we do not remove the programmer when running offline, we find the following phenomenon:

• Connect the USB-SPI programmer, the UART communication is back to normal
• Removal of USB-SPI programmer, UART Communication exception

We measured the waveform of each pin of the programmer with an oscilloscope and found that the programmer sent the SPI data to CSR8670 at a fixed time interval.

1.5. Who's the real killer?

I and the program ape J sorted out the conditions that would not occur with communication anomalies:

• USB Powered
• Connected to the USB-SPI programmer
• Mobile phone or other device with CSR8670 set up a Bluetooth link

At present, many wireless Bluetooth headset products in the market are CSR8670 this chip. The common feature of these headphones is battery power.

Since battery-powered products need to work long hours after filling a single charge, the system will require the systems to minimize the power consumption as much as possible in device selection and software design.

In summary, the chip is likely to have a low-power mode. In low power mode, the function of the UART is likely to be affected.

2. Power-saving mode

Log in to the CSR developer account, search for the keyword low power, and there is an article in the query results Bluecore power saving Mode.

The BlueCore chips has hardware support for both methods of reducing power consumption when the chip is idle:

• Shallow Sleep: The chip processor ' s clock speed is reduced. At the best this can reduce the current consumption to approximately 2 MA in bluecore01b, less on BlueCore2 chips. The processor ' s speed
  Can is restored within a few machine instructions, with a latency that depends on the slowed clock rate.

• Deep Sleep: Much of the chip ' s circuitry are shut down. At best, this can reduce the chip's current consumption to approximately 100μA on bluecore01b and less on BlueCore2 chips. However, it takes at least milliseconds to enter deep sleep and at least another ten milliseconds to exit deep sleep.

The document describes features specific to BlueCore chips; Bluetooth ' s own standard power saving support (hold, Sniff and Park modes) is mentioned only where they interact with the Chip ' s power saving modes.

The power consumption of these two modes is not the same. In the description of deep sleep, it is mentioned that multiple circuits of the chip are closed, which may also include the UART-related circuitry.

In deep Sleep, the processor, the fast (16MHz) clock and much of the digital and analogue hardware is shut down. This have a major effect on power consumption

When the device enters deep Sleep, it sets an alarm clock (a timed event from a counter that's clocked by the slow clock) . The timed event normally wakes the chip, but it can is woken prematurely by activity on the UART or USB.

In deep sleep mode, the chip is woken up every 1ms and can also be activated by the UART or USB.

Deep Sleep cannot was used when the chip had a USB host connection and the connection is in its USB "active" state.

This is why the UART communication of the demo board does not occur abnormally.

Once the system is in deep Sleep with only a limited set of stimuli can rouse it:

• Expiry of a timer (clocked from the chip ' s slow clock)
• When configured to provide a UART, an activity on the data-receive pin. (including asserting a break condition, e.g., to force a reboot.)
• When configured to provide a UART, activity on the CTS line (this is configured with the PS Key pskey_deep_sleep_wake_cts. )
• Bluecore2-external can configured to wake on PIO activity
• When configured to provide a USB host connection, an activity on the data lines
• Any activity on the chip's SPI port (Pstool.exe relies on this to read and write PS Keys if the chip was in deep Sleep.)
• System reboot

The data at the SPI Port activates the chip, which is why communication is not unusual when the USB-SPI programmer is connected.

3. Anomaly Analysis

Recalling chapter 1.1 of the phenomenon, why would lost data always in the first few bytes?

In a non-deep sleep state, the CSR8670 receives an instruction from the MCU and submits 2 times to the UART task Message_more_data.

In the deep sleep state, CSR8670 may only send the 2nd message_more_data to the UART task, and the 1th message_more_data is discarded.

3. Fix exceptions

In order to receive instructions from the MCU normally, CSR8670 can choose one of the following strategies:

• Do not use deep Sleep
• Wake from deep sleep before the MCU sends instructions

3.1. Do not use deep Sleep

Set the Pskey_deep_sleep_state to 0 with the Pstool tool.

3.2. Use deep Sleep

Set the Pskey_deep_sleep_state to 1 with the Pstool tool.

3.2.1. Wake up with the signal on CTS line

The PS Key pskey_deep_sleep_wake_cts (0x23c) can is set to allow a transition on the UART CTS line to WAKE the host from D Eep Sleep; This can provide an alternative to sending a short "wake up" packet.

3.2.2. Wake with Pio

The PIO port continues to drive output signals when the chip drops into deep Sleep.

For a button on a headset, a common technique are to route the button's signal to an input PIO pin and also to the UART CTS Line. Activity on the CTS line can then wake the chip.

3.2.3. Waking up with wake-up packets

The chip is eligible-enter deep Sleep if there have been no UART traffic from the host for at least one second and if th ere is no data waiting to being passed to the host.

The "one second" is actually the value of the PS Key pskey_uart_sleep_timeout (0x0222).

The MCU can send a wake-up packet and wait for more than 10ms before sending the command packet.

CSR8670 serial communication exception after running offline